目前许多项目都使用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在敏捷项目中有一些缺点，具体可见这篇文章：《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分支合并为了一个分支。

图如模型下：

流程是这样的：如果开发者要开发一个新的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的开发流程：

一般我们在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上当天的代码提交就行了

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