中型研发团队使用Git的分支管理机制
版本管理工具里面的分支管理一直是困扰开发团队的一个大问题，这里我总结了我们团队使用的分支管理以及开发测试发布环境管理机制。
分支命名和管理
-
现有的主线（master），对应的集成测试环境
-
新建prod分支，用于对应线上正式环境（生产环境）
-
上述两个分支的代码和集成，正式环境保持完全一致，如果有版本撤回的操作，代码也要做对应的操作
-
上述两个分支的合并和发布权限仅限个别的项目负责人
新开迭代的分支操作流程
-
产品经理召开迭代启动会，确定本次迭代包含的功能和bug范围
-
相关的开发负责人按照迭代编号或者功能名称从prod创建迭代分支
-
相关的开发从迭代分支开自己的分支做开发
-
开发完成后，从自己的分支发布功能测试版本（本地或者内网环境）
-
功能测试完毕，需要发布集成测试时，先从自己的分支合并到迭代分支，再由项目负责人合并主线，发布集成环境
-
集成环境测试通过，项目负责人把主线合并到prod分支，再发布正式
举例：
- 产品经理打算开展新的迭代，迭代编号为SL2.0.036
- 开发主管从涉及到的项目的prod分支分别创建名为“sl2.0.036”的迭代开发分支。
- 开发人员A从行程的迭代分支“sl2.0.036”再创建自己的开发分支“sl2.0.036_a”，在这个分支上做开发，开发完成后把自己的开发分支“sl2.0.036_a”合并到迭代分支“sl2.0.036”，基于迭代分支发布功能测试站点。
- 如果还有别的人也参与这个迭代的开发，并且也要改动行程的代码，比如说B也要参与这个开发。那么B也从行程的迭代分支“sl2.0.036”创建自己的开发分支“sl2.0.036_b”。
- 如果A和B的代码有必要合并之后统一发布一个功能测试站点，那么A和B分别把自己的分支合并到迭代分支“sl2.0.036”，然后再基于迭代分支发功能测试站点。
- 功能测试完成后，由开发主管统一负责把这个迭代涉及到的各个项目的迭代分支合并到主线（master）分支。并基于master分支发布集成测试。
- 集成测试完毕之后，由开发主管负责把涉及到的各个项目的master分支和prod分支合并，然后发布生产环境。
紧急版本发布操作流程
-
从prod切出fix分支，做紧急修复
-
从fix分支发布功能测试
-
如果改动很小，fix分支直接合并prod，发布正式
-
如果需要再做集成测试，那么fix分支合并到主线，发布集成，做测试，再fix合并到prod，发布正式
-
举例：
- 今天线上客户反馈机票查询有问题，经过检查机票后端需要做修改。
- 由机票后台的开发A从机票后台项目的prod分支切出紧急修复的分支，紧急修复的分支统一以fix加日期和bug描述命名，比如“fix_20190227经停航班查询问题”
- 在紧急修复的分支修改完成后，基于紧急修复的分支发布功能测试站点
- 功能测试完成后，开发主管把紧急修复的分支合并到master，重新发布集成测试站点
- 集成测试完成后，开发主管把机票后台项目的“fix_20190227经停航班查询问题”合并到prod，发布生产环境
命名约定
-
分支名称里面的英文都全小写
-
各个项目的master对应集成环境，prod对应生产环境
-
紧急修复的分支以fix_+日期+问题描述命名，例如“fix_20190227经停航班查询问题”
-
迭代分支以迭代名命名
关于代码Review的时机
- 如果是正常的迭代，在个人的开发分支合并到迭代分支时做review
- 如果是紧急修复，在个人分支合并到master或者prod的时候做review
关于分支合并
分支合并的原理：不同的分支上包含有不同的提交的改动，两个分支合并，就是把其中一个分支（A）上的改动都移动到另外一个分支（B）上。比如A和B往回追溯，两个分支岔开的时间点在一个月之前，那么把分支A合并到分支B实际上就是A分支上这一个月以来的改动都做到B上。
合并冲突的解决：既然合并代码的实质是往某个分支上提交一堆改动，那么就很容易出现各种改动的冲突。一旦出现改动冲突，哪怕只是修改到了同一个文件的不同行，在git里面也会认为是有需要解决的冲突。比如说A分支包含某个提交，这个提交涉及到a,b,c三个文件的修改，B分支的某个提交涉及到c,d,e三个文件，需要解决的冲突是两个提交对文件c的修改，但是实际上解决冲突的changelist里面会把a,b,c,d,e都放出来，解决完c的冲突之后，这五个文件需要重新提交上去。如果不提交a,b,d,e，就会造成所谓的“丢修改”的问题产生。
分支合并实际操作流程：一般来说，分支合并的方向都是从支线往主线合并。比如说迭代分支合并到主线，开发分支合并到迭代分支。但是实际操作时，一般会这么操作：把支线分支A合并到主线分支B时，一般会先把B往A合并，这样实际上是把从A切出来之后合并到B的所有改动都移动到了A上，这个合并的过程中可以基本上解决各种冲突，开发甚至可以基于合并之后的A分支再发一版功能测试。然后再把A合并到B就不太会有冲突。
关于Git的分支合并，有机会再开专题讨论吧。