敏捷模式下的分支管理

在原先的文章中已经介绍过了：

• 《GitFlow简明教程》
• 《GitHubFlow及GitLabFlow简明教程》

但是在实际的敏捷开发实战中，更多的公司会有如下的需求：

• 两周开发一个版本，单个版本一周开发一周测试；
• 多版本并行，先前的版本进入测试阶段，后续的版本就开始开发了；
• 某个版本的需求内容不固定，视实际情况需要砍掉需求或者新增需求；

如此，先前的GitlabFlow也显得不是很灵活，不能很好地满足敏捷的需要。在调研别的公司的分支管理模式及结合自己的工作经历后推荐使用如下的分支管理方法。

一、分支管理

1.1 master分支

主干分支是长期分支，是所有其它分支的上游分支，它的直接下游分支有release分支和hoxfix分支。

只有当release分支或者bugfix分支上的内容完成生产发布且验证无误后，才从release分支合并到master上，如此，master主干分支上的内容就是极度稳定可靠的，每个版本都打一个tag，标记里程碑。

1.2 release分支

发布分支是短期分支，代表一个版本的发布时间窗口，从master分支创建而来，任何人不能直接在release分支上提交代码，所有的内容必须从feature分支合并而来。

发布版本的时候从release分支进行发布，验证有问题可在该分支上继续修改，发布完成后再合并到master分支上，等到master上打了相应的tag，该发布分支就结束，可以删除了。

1.3 bugfix分支

修复分支是短期分支，仅在有生产BUG需要修复时，从master分支创建而来，同样的，任何人不能直接在bugfix分支上提交代码，所有的内容必须从feature分支合并而来。

布版本的时候从bugfix分支进行发布，验证有问题可在该分支上继续修改，发布完成后再合并到master分支上，等到master上打了相应的tag，该发布分支就结束，可以删除了。

1.4 feature分支

特性分支是短期分支，开发人员从release分支创建而来，进行具体某个功能的开发，开发完成后合并到要发布的release分支上即可，合并完成，该分支就可以删除了。

二、场景操作

2.1 单一版本管理

从master分支新建release分支，开发人员从release分支创建自己的feature分支，完成开发后合并到release分支，测试基于release分支进行测试和生产验证，确认没有问题后，基于release分支进行生产正式发布。完成发布后，release分支合并到master分支上，master分支上打上当前版本的tag，删除release分支。

2.3 多版本并行管理

第一个版本releaseA的管理同2.1，如果先前的版本还没有发布，此时开发要进行下一个版本的开发，只需从master分支再创建一个新的releaseB分支即可，如果releaseB依赖releaseA的部分还未上线的内容，可以先将releaseA的内容合并到releaseB上。等到releaseA发布并合并到master之后，再从master合并一下到releaseB上即可。

2.4 需求变更管理

假设releaseA有两个特性feature1和feature2，如果feature1不需要了，那么feature1不要往releaseA上合并即可。如果已经合并才决定不需要该特性了，那么可以重新从master分支拉取releaseA分支，再将需要的特性合并上去即可。

2.5 修复生产问题

从master分支新建bugfix分支，开发人员从bugfix分支创建自己的feature分支，其余部分内容同2.1管理。

如果还有其它我没有想到的场景，欢迎留言，一起看看当前的分支管理模式能否满足你的场景需要。