基于Git的分支管理模型

2019-07-04 07:57:37

阅读次数 - 808

架构 Git TBD

目前许多项目都使用Git来做版本管理。基于此,有几种主流的代码分支管理模型:

  • Git Flow
  • GitHub Flow
  • Trunk Based Development

Git Flow

Git Flow是Vincent Driessen于2010年发表的一篇文章提出的:《A successful Git branching model》

开发者如果要开发一个新的功能(feature),需要从develop分支checkout一个新的feature分支,然后做自己的修改。修改完成后,merge回develop分支。

如果合并的时候发生了冲突,开发人员需要处理完冲突再合并。

一般会给develop分支在CI系统中创建一条pipeline。开发人员合并会develop分支后,就会触发一条新的构建流水线。如果pipeline构建失败了,开发人员应该尽快修好它。

如果想要release,就切一个release分支,创建一条新的CD pipeline。release成功结束后,一般会merge回master分支,并在master分支打下版本Tag。

如果release之后发现有bug,需要紧急处理,我们称为hotfix,那就从master分支的某个Tag切出来,修复好问题后merge到master,打下新的版本Tag,并merge回develop分支。

模型图如下:

Git Flow

而Git Flow在敏捷项目中有一些缺点,具体可见这篇文章:《Gitflow有害论》。总结起来就是Git Flow基于feature分支开发,可能会使得feature分支存活时间太长,由此带来的merge困难,很难持续集成(CI)等。

it’s not that feature branches are bad, but that long-lived branches are bad.

GitHub Flow

GitHub的Scott Chacon于2011年提出了GitHub Flow。GitHub的官方文档有教程。

GitHub Flow只有master和feature分支,相当于把master和develop分支合并为了一个分支。

图如模型下:

Github Flow

流程是这样的:如果开发者要开发一个新的feature,就基于master拉一个新的分支。小步提交自己的修改,然后提交PR(pull request),这时候可以由其它人review这个PR,相当于代码评审。如果PR通过后,可以单独部署这个分支,进行最后的测试。如果部署通过,再merge回master,并删掉feature分支。

可见使用GitHub Flow后,只用到了两个分支,并且可以践行了小步提交、Code Review、及早测试等等敏捷实践。

GitHub上很多开源的项目都是使用的GitHub Flow。它对GitFlow做了一定的精简,使得代码开发的流程更加适应敏捷。但仍然使用了feature分支,所以也会存在一些长期持有feature分支存在的一些问题。

Trunk based Development

Trunk based development(主干开发)模型简称TBD,起源于2013年发表的一篇文章:《What is Trunk-Based Development?》

TBD也是Google,Facebook,ThoughtWorks等公司内部广泛采用的代码分支管理模型。参考官方文档,示意图如下:

TBD

TBD的开发流程:

一般我们在master分支(即主干分支)上进行开发。

开发人员当天开始修改代码之前,先pull获取远程代码。这里注意需要选择rebase方式而不是merge方式:

git pull -r

开发人员在本地可以直接在master上进行修改,提交。也可以checkout一个短期的临时分支,修改完成后在本地rebase到master分支。

PS: 使用rebase而不是merge,可以让你的代码只有一条master分支线,让你的代码提交记录看起来更整洁,尤其是使用一些git可视化工具的时候,你可以看到所有的commit记录都在master这一条分支上。

开发人员要保证及时push自己的修改到远程的master分支,一般是一天一次。这样就能保证远程master分支上的代码是最新的,且不需要大面积地处理冲突。而且这样可以每天下午固定时间,团队一起进行code review,保证代码质量。

需要release的时候,直接从master分支checkout一个release分支。可能你会有一个疑问:那master分支上可能有我不需要release或者还没开发完的feature,怎么办呢?

有两种方法可以处理:

  1. 如果你的提交记录不多,可以采用git cherry pick工具来选择部分的commit记录。
  2. 使用Toggle开发,我们称为feature toggle。甚至有一些开源的框架支持,比如:Togglelz,更多项目可以查看这篇文章

一般来说,敏捷开发提倡小步提交,而且一旦团队人数稍多,第一种方式就不太合适。所以选择第二种方式的比较多。但Toggle方法也有其弊端,就是开发的时候需要考虑toggle,加大了开发的任务量;而且一旦toggle确认不再使用,管理toggle和移除toggle也会带来更大的effort。

但我们可以在团队管理和release plan上一定程度减少toggle的产生。比如计划好一个时间release,在那个时间点前,尽量只开发且开发完期望的feature。

总结

不同的分支管理模型适用于不同的项目和团队,没有最好的模型,只有最适合自己的模型。

我司内部主推Trunk Based Development,因为它相比于另外的模型来说,具有以下优势:

  • 更好地持续集成,可以经常触发新的持续集成pipeline,至少每天一次
  • 更少的合并冲突,因为开发人员每天都是基于最新的代码修改
  • 更好的code review,只需要review master上当天的代码提交就行了

当然,它对团队的敏捷程度,团队成员的协同合作能力要求较高。

感谢阅读


觉得文章还不错?点击下方按钮分享吧!

评论

快来占个沙发吧~


TO: