Git分支管理策略

阮一峰，行业大佬的文章

Git分支管理策略

常用 Git 命令清单

Git远程操作详解

先割为敬，上图

 

• develop  开发分支
  模块责任人负责，作为日构建分支，此分支有代码更新时需要自动触发流水线构建，代码静态检查，单元测试覆盖率，基础接口测试。
• master  唯一主分支
  架构师负责，提供给外部用户的正式版本分支。

• feature-xxx
  特性分支， 开发人员负责，迭代开启时，从develop分支拉出，提交迭代代码。开发完成后提交merge request，由模块负责人review后将代码合入develop分支。
• release-xxx
  发布分支,  测试人员负责 开发人员提测，由测试人员将develop分支代码合入release分支，进行接口测试，功能等测试。
• bugfix-xxx
  问题修复分支，测试人员负责，从release-xxx上拉取分支，修复测试阶段出现bug后，在此分支上提交。问题修复后，将代码回合release-xxx。测试人员同时提交merge request，由模块责任人确认后将代码合入develop分支。
• hotfix-xxx
  紧急修复分支，架构师负责，从release-xxx分支上拉取。预生产环境和生产环境出现bug需要紧急修复的，在此分支上修复，修复后，开发人员提交合并请求，架构师评审之后，将代码回合至release-xxx分支。其实这一步也不是万全之策，生产中有过照样出事的经历，真是煎熬，这就要考验架构设计能力之处，对项目限流、容错、断流等架构设计能力了。

• 架构师/产品负责人确认本迭代发布成功后，由架构师将release-xxx代码合入master分支。由各自模块责任人负责比较模块develop分支和master分支差异。
• 本次迭代发布成功后，删除feather-xxx，bugfix-xxx,hotfix-xxx临时分支。保留当前release-xxx分支。删除历史release分支。
• 生产发现的历史遗留紧急bug,需要在最近的release-xxx，回归测试后，由架构师将relaese-xxx分支merge至master分支，由架构师提交merge request ,将release代码回合至develop分支。