版本管理工具里面的分支管理一直是困扰开发团队的一个大问题,这里我总结了我们团队使用的分支管理以及开发测试发布环境管理机制。
分支命名和管理
- 现有的主线(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分支合并,然后发布生产环境。