团队项目的Git分支管理规范

许多公司的开发团队都采用Git来做代码版本控制。如何有效地协同开发人员之间，以及开发、测试、上线各环节的工作，可能都有各自的流程与规范。本文分享的是作者一直沿用的团队项目Git分支管理规范，希望给有缘阅读的人以参考，如果有更好的实践，也欢迎探讨、交流。

分支管理

创建项目时（一般是服务型项目，工具型或辅助型项目可以简单一些），会针对不同环境创建三个常设分支：

• master: 生产环境的稳定分支，生产环境基于该分支构建。仅用来修复线上BUG，除了从release或生产环境Bug修复分支进行merge，不接受任何其它修改。
• release：生产通关测试完毕的稳定分支，仿真环境基于该分支构建，由测试完成的 test 分支稳定后改名。
• test：测试环境的稳定分支，测试环境基于该分支构建，由测试完成的 develop 分支稳定后改名。
• develop：开发环境的稳定分支，公共开发环境基于该分支构建，由上个版本的 master 分支签出，合并当前所需要的版本的所有需求。

平时开发工作中，会根据需要由开发人员创建两类临时分支：

• 功能（feature）分支：为了开发某个特定功能，从develop分支上面分出来的。开发完成后，要merge到develop分支。功能分支的命名，可以采用feature/的形式命名(为需求名)
• Bug修复（fixbug）分支：为了修复某个bug，从常设分支上面分出来的。修复完成后，再merge到对应的分支。Bug修复分支的命名，可以采用fixbug/的形式命名（为bug内容）

流程规范

新版本开发流程

• 1. 从“master”分支切出一个新的分支“develop”基线。
• 2. 从“develop”分支切出一个新分支，根据是功能还是bug，命名为feature/* 或 fixbug/*。
• 3. 开发者完成开发，提交分支到远程仓库。
• 4. 开发者发起merge请求（可在gitlab页面“New merge request”），将新分支请求merge到develop分支，并提醒code reviewer进行review
• 5. code reviewer对代码review之后，若无问题，则接受merge请求，新分支merge到develop分支，同时可删除新建分支；若有问题，则不能进行merge，可close该请求，同时通知开发者在新分支上进行相应调整。调整完后提交代码重复review流程。
• 6. 提测时，直接从当前develop分支push到test分支，若存在多个版本则test分支带版本号例如test/v6.0.2，重新构建测试环境完成提测，测试期间发生的bug由test分支进行修复。
• 7. 测试完成时，直接从test分支push到release分支，重新构建仿真提测，仿真测试期间发生的bug由release分支进行修复。
• 8. 仿真测试完成时，release 稳定时，将将release推送到master的最新代码进行打Tag，Tag名为“v6.0.1”（即版本号）
• 9. 如果此时有其他分支正在提测，则将master合并到具体提测分支，例如目前 v6.0.2和v6.0.1 同时开发时，则将推送到master的 v6.0.1 反向合并到 test/v6.0.2 分支

新版本开发流程.jpg

并行开发仿真环境Bug修复流程

并行开发（即前一个版本已经仿真测试完成但未上线，后一个版本又已在开发中并部分合并到了develop分支）过程中，转测后测试环境发现的bug需要修复，但是develop分支此时又有新内容且该部分内容目前不计划转测，可以release切出一个bug修复分支。完成之后需要同时merge到release分支与develop分支。merge时参考“正常开发流程”。流程示意图如下

并行开发测试环境Bug修复流程.jpg

生产环境Bug修复流程

生产环境的Bug分两种情况：

紧急Bug：严重影响用户使用的为紧急Bug，需立即进行修复。如关键业务流程存在问题，影响用户正常的业务行为。
非紧急Bug或优化：非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急Bug，可规划到后续版本进行修复。

生产环境Bug修复流程.jpg

参考 半路雨歌的博客# 团队项目的Git分支管理规范