中型研发团队使用Git的分支管理机制

版本管理工具里面的分支管理一直是困扰开发团队的一个大问题，这里我总结了我们团队使用的分支管理以及开发测试发布环境管理机制。

分支命名和管理

1. 现有的主线（master），对应的集成测试环境

2. 新建prod分支，用于对应线上正式环境（生产环境）

3. 上述两个分支的代码和集成，正式环境保持完全一致，如果有版本撤回的操作，代码也要做对应的操作

4. 上述两个分支的合并和发布权限仅限个别的项目负责人

新开迭代的分支操作流程

1. 产品经理召开迭代启动会，确定本次迭代包含的功能和bug范围

2. 相关的开发负责人按照迭代编号或者功能名称从prod创建迭代分支

3. 相关的开发从迭代分支开自己的分支做开发

4. 开发完成后，从自己的分支发布功能测试版本（本地或者内网环境）

5. 功能测试完毕，需要发布集成测试时，先从自己的分支合并到迭代分支，再由项目负责人合并主线，发布集成环境

6. 集成环境测试通过，项目负责人把主线合并到prod分支，再发布正式

举例：

• 产品经理打算开展新的迭代，迭代编号为SL2.0.036
• 开发主管从涉及到的项目的prod分支分别创建名为“sl2.0.036”的迭代开发分支。
• 开发人员A从行程的迭代分支“sl2.0.036”再创建自己的开发分支“sl2.0.036_a”，在这个分支上做开发，开发完成后把自己的开发分支“s