许多公司的开发团队都采用 Git 来做代码版本控制。如何有效地协同开发人员在开发、测试、上线各个环节的工作,可能都有各自的流程与规范。本文就分享作者一直沿用的团队项目 Git 分支管理规范,希望给有缘阅读的人加以参考,如果有更好的实践,也欢迎探讨、交流,谢谢!
创建项目时,会针对不同环境创建几个常用分支:
feature
分支和 bugfix
分支都从该分支创建。develop
分支创建,创建之后由测试人员发布到测试环境进行测试,测试过程中发现 bug 需要开发人员在该 release
分支上进行 bug 修复,修复完成自测没问题后,在上线之前,需要合并该 release
分支到 master
分支,同时需要再合并该分支到 develop
分支。平时开发工作中,会根据需要由开发人员创建几类临时分支:
develop
分支创建,不同的功能创建不同的功能分支,开发完成自测没问题后,需要合并该分支到 develop
分支,之后删除该分支。develop
分支创建,修复完成自测没问题后,需要合并该分支到 develop
分支,之后删除该分支。master
分支创建,用于紧急修复线上的 bug,修复完成自测没问题后,需要合并该分支到 master
分支,以便上线,同时需要再合并该分支到 develop
分支,之后删除该分支。该分支的分支名称应该为描述该功能的英文简称:
feature/分支名称
例如,开发的功能为“新增商品到物料库”,则可以创建一个名为 feature/material-add
的分支。
该分支的名称应该为 Jira 中 bug 代码或者是描述该 bug 的英文简称:
bugfix/分支名称
hotfix/分支名称
比如,修复的 bug 在 jira 中代号为 MATERIAL-1,则可以创建一个名为 bugfix/MATERIAL-1
的分支。
该分支的名称应该为本次发布的主要功能英文简称:
release/分支名称
比如,本次上线的功能为“新增商品到物料库”,则可以创建一个名为 release/material-add
的分支。
develop
分支切出一个新分支,根据是功能还是 bug,命名为 feature/* 或 bugfix/* 分支。merge request
请求(可在 gitlab
页面 New merge request
),将新分支请求合并到 develop
分支,并提醒组长或同事进行 code reviewer
。code reviewer
后,若无问题,则接受 merge request
,并将新分支合并到 develop
分支,同时可以删除新建分支;若有问题,则不能进行合并,可 close
该请求,同时通知开发者在新分支上进行相应调整,调整完后提交代码,重复 code reviewer
流程。develop
分支合并到 release
分支,重新构建测试环境,完成转测。release
分支合并到 master
分支,基于 master
分支构建生产环境完成上线,并对 master
分支打 tag
, tag
名可为 v1.0.0_2019032115
(即:版本号_上线时间)。流程示意图如下:
并行开发(即前一个版本已经转测但未上线,后一个版本又已在开发中并部分合并到了 develop
分支)过程中,转测后测试环境发现的 bug 需要修复,但是 develop
分支此时又有新内容且该部分内容目前不计划转测,可以从 release
切出一个 bug 修复分支,完成之后需要同时合并到 release
分支与 develop
分支,合并时参考“正常开发流程”。
流程示意图如下:
生产环境的 Bug 分两种情况:
非紧急 Bug 修复参考“正常开发流程”。 紧急 Bug 修复,需要从 master
分支切出一个紧急 bug 修复分支,完成之后需要同时合并到 master
分支与 develop
分支(如果需要测试介入验证,则可先合并到 release
分支,验证通过后再合并到 master
分支上线),合并时参考“正常开发流程”。
流程示意图如下: