开发分支管理模型之阿里AoneFlow

说到分支管理模型，使人最为熟悉的莫过于TrunkBased 和 GitFlow。

TrunkBased 模型是持续集成思想所崇尚的工做方式，它由单个master分支和许多release分支组成，每一个release分支在特定版本的提交点上从master分支建立出来，用来进行上线部署和 Hotfix。在 TrunkBased 模式中，没有显性的feature分支。

GitFlow 模型是若干模式的集大成者，包含一个master分支、一个develop分支、许多的feature分支、许多的release分支和 Hotfix 分支，以及许多繁琐的合并规则。

基于这两种模型，演变出了不少的新模型，而阿里的AoneFlow，它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特色，同时规避掉 GitFlow 的那些繁文缛节。

AoneFlow 只使用三种分支类型：master分支、feature分支、release分支，以及三条基本规则。

规则一，开始工做前，从master建立feature分支。

从表明最新已发布版本的master分支上建立一个一般以feature/前缀命名的特性分支，而后在这个分支上提交代码修改。也就是说，每一个工做项（能够是一我的完成，或是多我的协做完成）对应一个特性分支，全部的修改都不容许直接提交到master分支。

规则二，经过合并feature分支，造成release分支。

从master分支上拉出一条新分支，将全部本次要集成或发布的feature分支依次合并过去，从而获得release分支。release分支一般以release/前缀命名。

规则三，发布到线上正式环境后，合并相应的release分支到master分支，在master分支上添加tag，同时删除该release分支关联的feature分支。

为了不在代码仓库里堆积大量历史上的feature分支，还应该清理掉已经上线部分feature分支。若是要回溯历史版本，只需在master分支上找到相应的版本的tag便可。

除了基本规则，还有一些实际操做中不成文的技巧。好比上线后的Hotfix，正常的处理方法应该是，建立一条新的release分支，对应线上环境（至关于Hotfix分支），同时为这个分支建立临时流水线，以保障必要的发布前检查和冒烟测试可以自动执行。

其实还有一种简便方法是，将线上正式环境对应的release分支上关联的feature分支所有清退掉，在这个release分支上直接进行修改，改完利用现成的流水线自动发布。

若是非得修一个历史版本的Bug怎么办呢？那就老老实实地在master分支找到版本tag位置，而后从那个位置建立 Hotfix分支。

所谓模型，在不一样的开发团队，不一样的文化，不一样的项目背景状况下都有可能须要进行适当的裁剪或扩充。