开发分支管理模型之阿里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分支。
开发分支管理模型之阿里AoneFlow_第1张图片

规则二,通过合并feature分支,形成release分支。

从master分支上拉出一条新分支,将所有本次要集成或发布的feature分支依次合并过去,从而得到release分支。release分支通常以release/前缀命名。
开发分支管理模型之阿里AoneFlow_第2张图片

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

为了避免在代码仓库里堆积大量历史上的feature分支,还应该清理掉已经上线部分feature分支。如果要回溯历史版本,只需在master分支上找到相应的版本的tag即可。
开发分支管理模型之阿里AoneFlow_第3张图片

除了基本规则,还有一些实际操作中不成文的技巧。比如上线后的Hotfix,正常的处理方法应该是,创建一条新的release分支,对应线上环境(相当于Hotfix分支),同时为这个分支创建临时流水线,以保障必要的发布前检查和冒烟测试能够自动执行。

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

如果非得修一个历史版本的Bug怎么办呢?那就老老实实地在master分支找到版本tag位置,然后从那个位置创建 Hotfix分支。

所谓模型,在不同的开发团队,不同的文化,不同的项目背景情况下都有可能需要进行适当的裁剪或扩充。

你可能感兴趣的:(git,git-flow,分支管理,版本管理)