Git flow分支管理策略

Git flow分支管理策略

Git flow分支管理策略

​ Git flow分支管理策略是一种Git版本控制工作流（分支策略管理模型），规定了使用master分支来管理发布历史，用develop分支来作功能代码集成；使用feature分支来作功能开发，使用release分支来作版本发布，使用hotfix分支来作生产环境缺陷紧急修复。

​ Git flow分支管理策略工作流如下：

各个分支说明如下：

分支	分支类型	说明
master	长分支	缺省分支，用来记录生产环境发布的历史
develop	长分支	开发集成分支，用来集成功能开发代码
feature-	短分支	功能开发分支或特性分支，用来开发某个功能特性
release-	短分支	版本发布分支，用来准备某次版本的发布
hotfix-	短分支	紧急修复分支，用来修复某个生产缺陷

[1] Master和Develop分支

[1-a] 在master分支基础上创建出develop分支。

维护两个长期分支：master和develop分支。其中master分支为缺省分支用来记录生产环境发布的历史，develop分支用来集成功能开发代码。

每次版本合并进master分支上通过打tag版本号来标记本次版本所有代码提交。

[2] Feature分支

[2-a] 开发人员按功能开发的要求从develop分支基础上创建出feature分支，feature分支命名为：feature-，item_id为项目管理软件上的任务ID。比如项目管理软件有一个任务ID为1，则需要在develop分支基础上创建出feature-1分支来开发该任务的功能。

[2-b] 开发人员在feature分支上开发代码。

[2-c] 在某个feature分支开发完成且评审通过后，代码评审者将该feature分支合并进develop分支，并删除该feature分支。

Feature分支不是一条分支，而是每个任务一条feature分支；不允许将feature分支直接合并进master分支。

[3] Release分支

[3-a] 开发经理在准备版本发布时，先通知项目组开发人员暂停提交代码到develop分支，再从develop分支基础上创建出本次版本发布的release分支，release分支命名为release-，version为版本号。比如本次要发布的版本号为0.2.0，则需要在develop分支基础上创建出release-0.2.0分支来作该版本发布。

创建完release分支后，开发经理通知项目组开发人员可以继续提交代码到develop分支。

开发经理触发持续交付流水线对本次版本发布的release分支作代码构建和镜像打包，镜像标签为本次发布的版本号。

运维工程师选择本次版本号的镜像去部署到测试环境，测试工程师在测试环境进行测试。

[3-b] 如果测试发现问题，开发人员从该release分支基础上创建出feature分支作bug修复，bug修复后再合并进该release分支，重新构建打包和部署测试。

如果测试通过，运维工程师将该版本的镜像部署到生产环境。

[3-c] 生产环境版本发布成功，开发经理将该release分支的代码合并进master分支，并在master分支打tag（tag为版本号）来标记版本提交记录。

[3-c] 同时将该release分支的代码合并回develop分支；然后将该release分支删除。

Release分支不是一条分支，而是每个版本一条release分支。

[4] Hotfix分支

[4-a] 如果生产环境发生严重缺陷，需要紧急修复，开发人员从master分支基础上创建出Hotfix分支，Hotfix分支命名为：hotfix-，item_id为项目管理软件上的缺陷ID。

[4-b] 在生产环境紧急修复完缺陷后，需要将hotfix分支合并进master分支，并在master分支上打新的tag（tag命名在版本号最后一位记录<修复小版本号>，比如0.2.0版本上的第一次Hotfix的tag为：0.2.1来标记缺陷修复提交记录。

[4-c] 并将该hotfix分支代码合并回develop分支，然后将该hotfix分支删除。

Hotfix分支不是一条分支，而是每次缺陷紧急修复一条hotfix分支。

参考文档

• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow