Git版本控制和重叠项目发布Git强大的版本控制功能使您可以灵活地在项目中创建和合并分支。 但是，灵活性总是伴随着复杂性。 例如，当项目团队变大时，创建的分支非常多，每个人都可能创建一些。 如果不立即提交代码、合并并删除不需要的分支，或者为分支创建命名约定，则可能会出现混乱。
实战项目通常有多个环境，包括开发环境、测试环境和生产环境。 也可以是灰度环境、UAT环境或预发布环境。 一般来说，测试环境和生产环境是必需的。
在小型团队中，Git和SVN一样提供提交、合并代码的功能。 在迭代开发中，也只需2、3名工程师定期合并并发布代码即可，但在大型团队中问题会变得明显。 例如，如果一个大型团队分为几个组，每个组负责开发几个模块，则各组之间的开发是异步的，如果共享一组代码就会出现问题。 例如，A、b、c、d这四个项目组有的本周发布三次，有的下周一发布。 如果代码是一个project的话就麻烦了。
例如，我们的项目是一组代码，为了规格我们决定每周三晚上发布，其他的项目都按照这个计划执行，但是只有一个项目，所以假设a项目完成了开发测试，这周的水虽然这在SVN管理时很难实现，但Git提供了强大的版本控制功能，每个项目组可以完全不同
在最初的功能发布不同步问题中，只有一个主分支，但由于主分支是缺省分支且要求权限，因此所有工程师都将代码提交给dev分支以进行测试和生产发布如果代码提交给dev分支，那么所有开发的代码每周都会得到保证
此时的过程如下。
但是，发生了问题。 我们同时开发着两个功能。
功能1 )本周功能2 )下周上线。 本周和下周的开发测试此时在dev上有功能1的提交和功能2的提交。 本周三个dev编译上线后，功能2的未完成代码也将上线。 我们确实这么做了。 也发生了问题。
用户生气了，功能在线了吗？ 测试要把我们大卸八块。
为了避免这些问题，有人建议创建一个只有测试完成的代码才能在线的test分支。 为了避免在线时出现任何意外，不是在周三晚上将test的代码合并到master后再发布，而是正式发布test的代码，确认验证无误后，在第二天早上将test合并到master
但是，将test分支代码发送到生产环境似乎不太友好，该怎么办？ 再做一个release分支吧。 这个分支存储了通过验证的所有代码。 实际上，release是test。 在通过test的代码测试后将test集成到release中。
此时的方案如下。
1、日常开发中可以将所有代码提交给dev。 dev分支是所有开发工程师代码的最新集成。
2、dev分支的内容可以在【开发环境】中公开验证。 验证完成后，将代码集成到test分支中并发布测试；
3、测试完成后，将测试完成的代码编入release代码
4、每周三将发放代码发放到正式环境中，验证完毕后第二天早上将发放代码合并到主控中。
我们将dev定义为【所有开发中的代码】，test定义为【所有测试中的代码】，release定义为【所有世代发行的代码】，master定义为【所有在线化的代码】。 这样的定义非常明确，但问题是【所有测试中的代码】也就是包含本周三在线的代码和下周三在线的代码
更麻烦的是，工程师必须将代码提交给dev，要测试的代码也必须提交给test。 这个行不通。
让我们再仔细研究一下这个问题：
假设：
工程师d负责功能1的开发，需要在本周内完成开发测试并发布生产
工程师d、g共同负责功能2的开发，下周完成测试生产。
方案：
1、为了防止冲突，工程师d在功能1开发完成后无法参与功能2的开发。 否则，功能1和功能2的代码将混合在一起提交给测试，影响本周的发布
2、工程师d在功能开发后，集成到dev分支中，发布到开发环境验证(工程师d自行验证)
3、如果没有问题，可以将提交给dev的commit发送给test分支(工程师d在开发完成前不提交dev，开发结束后一次性提交！ )；
4、工程师g可以同时开发功能2，将代码提交给dev，但不能提交给test分支
5、功能上线后，工程师d与g一起完成功能2，然后提交dev发布到开发环境进行自我验证
6、验证成功后，D和g将提交给dev的commit再次提交给test进行合并，并在测试环境中发布测试。
7、如果没有拆分在线的情况，应将dev合并为test，避免两者相差过大。
git将代码同时提交到另一个分支
1 .先在当前分支上提交代码2. git log查看刚才
提交的 commit id3. 切换分支4. git cherry-pick commitId5. git pull6. git push问题：
工程师D在dev上的验证可能会有问题，再反复修改，多次提交，要把这几次提交的id都记下来，将来全部转到test分支，操作起来相当麻烦；
在功能一开发过程中，G的代码也会阶段性提交到dev，可能与工程师D的代码冲突，或影响功能；
为了解决功能不同时上线的问题，对分支的操作很多，要花费大量的时间合并，如果出现误操作，要花更多时间去解决，保证test分支上是本次要发布的纯净代码，付出的代价非常大，得不偿失。
如果不要dev分支呢？
如果不要dev分支，那么当前git库中就没有一个分支是当前最全的代码；并且，每个工程师都想到开发环境验证问题怎么办？每个人的代码都与别人不同，你发一版，我过会也发一版，我把你发布的覆盖，再过会我的也被人覆盖了，更没法玩了。
上面我们考虑的test分支是固定的，其实我们的敏捷开发是迭代进行的，每一轮测试也是迭代的，不如我们每轮迭代创建一个test分支，本轮迭代完成就合并删除它，再建一个新的。
方案
1、把需要本次迭代的代码提交到当前测试分支 test-v4.5.1 ；
2、如果D即要开发 test-v4.5.1 功能，也要开发下轮迭代 test-v4.5.2 功能，则优先开发本轮迭代，发布后再做下一迭代功能。或者保证把本轮迭代的代码发到 test-v4.5.1 ，下轮迭代的代码提交到dev分支。
3、test-v4.5.1测试通过后合并到本轮release-v4.5.1分支，删除test-v4.5.1 。
4、release-v4.5.1发布生产验证后，合并到master，删除release-v4.5.1 。
5、创建下个迭代test-v4.5.2与release-v4.5.2分支，合并dev的代码到。
6、需要开发next sprint的工程师切换到test-v4.5.2,其他工程师切换到dev。
总结一句话：本轮迭代的代码提交到current sprint中，下轮代码的代码提交到dev中，再往后的才发布的代码自建独立分支。
这种方案中，dev中不一定是最全的代码，因为当前迭代中有些代码是直接提交到test中的（避免代码同时要提交到两个分支），但是没关系，我们只要保证需要的代码上线即可。在当前迭代中，test确定是当前所有测试的代码，而release也确实是测试通过后合并进来的代码，我们仍然在周三晚上发布release中的代码，在周四早晨把release中的代码合并入master。
问题：
1、如果有功能三，要下个月发生产，H可能已经往dev中提交了一部分代码，此时，从dev创建next sprint的代码就会把H的代码也复制到next sprint中，这就不合理了。
而若从master创建next sprint分支，则功能二开发的部分代码又不在next sprint中。
所以，对于非current sprint，也不是next sprint的代码，建议一开始就从master建一个分支独立开发，开发完后再合并到current sprint中，而新建的next sprint则要合并master与dev的代码。
2、如果我们把test中代码测试通过了，test->release后也把test给删除了，周三晚上，我们把release中代码编译发布到生产环境，结果发现个bug（你知道测试往往做不到充分，总会有什么事发生），怎么办？
此时已经没有test分支了，一般如果bug影响严重，需要用master分支（上一版）来覆盖，如果不太严重，可能要修改少量代码，这里可以切换到release分支上，改完后，把release编译发到测试环境验证，没问题再用release发生产。
最终方案实际上release分支的确没什么卵用，它只是test的最终快照，测试完成时，一般就到了上线时间，所以直接拿test完成的结果发生产没有问题，操作上还能简化一些，因为我们下个迭代只用创建一个新的test，把dev中代码合并进来即可，要不然还要再维护一个release，还得保证这两个分支的初始状态是一样的。
release只不过是掩人耳目的test，作为直耿且追求无尚简化的程序员，怎么能不“懒”一点呢？
1、保证dev中是下轮迭代要发布的代码，test是本轮迭代要发布的代码，其他长期功能另建分支开发，如果不确定是否是在本轮或下轮能完成的功能，也要另建分支，等确定后再合并到dev或test中。
2、注意代码提交的位置，如果不小心把要test的代码发到dev，则自行把相关代码重新发到test；如果把要发dev的代码发到test，则要撤回。
3、另外，在test合并到master后要合并dev的内容，记住：每次切换分支后，先pull request，把远程代码拉取一下，以保证合并时有完整的代码。
远期分支的命名规范：
feature-[模块标识]-[帐号]临时分支（用来做某个功能、改个某个bug）命名规范：
temp-[dev/test]-[帐号]fix-[dev/test]-[帐号][功能]-[dev/test]-[帐号]版本号命名规范：
x.x.x #[大版本].[小版本].[迭代号：当前自然周] Git规范改进版经过一段时期的试运行，发现以上规则有一些问题：
1、大部分工作都在test分支上进行开发，只有极少量的工作在dev分支上做，造成dev分支形同虚设；
因为大部分项目/任务都是要近期上线的，没有谁愿意说自己的工作不着急，团队的敏捷实践并不完美，很多时候只会规划本期要上线的东西。远期的需求不确定什么时间能上线。
2、每次发版要把test合并到master，之后要把dev合并到test，但这样就会出现问题，首先，因为有些代码只提交到了test，在dev中是没有的，在下次迭代时，dev中因为缺少了一些代码而无法在开发环境验证；其次，在dev与test合并的过程中常常有大量的冲突出现，解决冲突需要很多沟通成本，而且容易出错；再者，如要保持迭代后dev与test相同，则需互相合并，或者dev合到test后再重建dev，这样dev和test实质上可以看做一个分支。
为了解决上面两个问题，我们采用两个主分支，test和master，去掉恒定的dev，如果有下次迭代的内容，可以从master新建临时的dev分支，这种dev分支是临时的，开发时只在本地验证即可，开发环境服务器一般不用发布，所以不同人可以有不同的dev临时分支。
分支规范示意图：
分支命名规范
#远期分支的命名规范feature-[模块标识]-[帐号]#开发分支dev-[帐号]# 修复bug用的分支fix-[bug号]-[帐号] #紧急发版的临时版本fix-master-[帐号]，从master建一个分支,修复验证后发版版本号命名规范：
x.x.x #[大版本].[小版本].[迭代号：当前自然周]