如何选择合适的开发模式

在确定选用哪种开发策略之前，我们需要回答出如下几个问题：

Google和Facebook等互联网巨头都在用的主干开发（Trunk Based Development，简称TBD），我们能否直接采用。
大名鼎鼎的“Git Flow（A successful Git branching model）”，真的好用吗？我们能否直接套用？
GitHub的Github Flow和GitLab的GitLab Flow有什么区别，适合我们使用吗？
国内知名互联网公司，都在使用什么样的分支策略？

而要回答出这几个问题，就需要我们对分支策略有一个比较全面的了解。

一、主干开发模式

在主干开发模式中，存在着两种形态：

主干开发，主干发布。直接在主干上集成，master分支可随时发布。
主干开发，发布发布。直接在主干上集成，除了一个用于发布的发布分支外，没有任何其他分支。必要时通过cherry pick的方式（选择部分变更集合并到其他分支），将部分变更合并到发布分支。

在现实场景中，往往会进行并行开发，这样就会产生一个问题：同一个应用会有多个团队同时提交不同需求的代码，并且每个需求发布的时间点是不同的。使用主干开发模式，势必会将没有经过测试验证的代码发布到线上。此时，就需要在代码里预设很多功能开关。这些开关可以在运行期间隐藏、启用或禁用特定功能。而这必然会增加代码的复杂度。

所有，就了特性分支开发模式。

二、特性分支开发模式

2.1、Git Flow

Git Flow是因git的流行，而产生的开发模式。它的特点是：

除了master分支之外，还会有一条常驻的develop开发分支；
所有的功能开发和缺陷修复都在develop分支上再建分支；
发布前会将develop分支合入到从master分支签出的release分支中，由releae分支来分布；
发布后会将release分支再合并回master和develop分支。

由于Git Flow的流程过于繁琐，现在少有团队会选择这种开发模式。

2.2、GitHub Flow

GitHub Flow是GitHub所使用的开发模式。它的特点是：

只使用master和特性分支，并会借助GitHub的pull request功能；
master分支所包含的是已经或即将发布的稳定代码；
未审核、未提交的代码不能提交到master分支；
任何修改（修改代码、修复Bug、热修复、新功能开发）都在单独的分支进行；
新分支开发完成后，提交pull request，审查、测试通过后合并到master

2.3、GitLab Flow

GitLab Flow是GitLab在GitHub Flow的基础上做的改良，它额外衍生出了三个子类模型。

2.3.1、带生产分支的GitLab Flow

说明：

无法控制准确的发布时间，但又要求不停集成
需要创建一个production分支来放置发布的代码

2.3.2、带环境分支的GitLab Flow

说明：

要求所有代码都在逐个环境中测试通过
需要为不同的环境建立不同的分支

2.3.3、带发布分支的GitLab Flow

说明：

一般用于对外界发布软件的项目，同时需要维护多个发行版本
尽可能晚地从master拉取发布分支
Bug的修改应先合并到master，然后cherry pick到release分支

三、选出最合适的分支策略

上面提到的分支模型，都是 IT 研发领域比较流行的。虽然有些策略带上了代码平台的标识，如 GitHub Flow，但并不意味着该策略仅限于 GitHub 代码平台使用，我们完全可以在自己搭建的代码平台上使用这些策略。接下来，总体归纳一下什么情况下应该选择什么样的分支策略：

主干开发。开发团队系统设计和开发能力强；有一套有效的特性切换机制，能保证上线后无需修改代码就能够修改系统行为。
Git Flow。不具备主干开发能力；有预定的发布周期；需要执行严格的发布流程。
GitHub Flow。不具备主干开发能力；随时集成随时发布：分支集成后经过代码评审和自动化测试，就可以立即发布的应用。
GitLab Flow（带生产分支）。不具备主干开发能力；无法控制准确的发布时间，但又要求不停集成。
GitLab Flow（带环境分支）。不具备主干开发能力；需要逐个通过各个测试环境验证。
GitLab Flow（带发布分支）。不具备主干开发能力；需要对外发布和维护不同版本。