一、目的

本文对行业内 主流分支管理模型 进行分析介绍，帮助读者快速找到适合自己的分支管理模型。

二、目标受众

本文假定读者熟悉git仓库的常用概念和命令，包括分支(branch)/标签(tag)/合并(merge/rebase)/cherry-pick等。

三、基本概念

1. 分支管理模型

该创建多少个分支，每个分支做什么用途，分支间如何互相影响。

选择不同模型的目的：

1）提高多人协作的并行度(降低等待，减少耦合，降低冲突)。

2）保证(不同分支的)代码的质量。

2. 如何选择分支管理 - 思考的维度

1) 是否要长期维护多个已发布的版本

    注：维护指发布包含了若干bug fix微小变动的新版本（版本号往往只变化最后一位，如从1.0.0变为1.0.1)。

    客户端App：发布一个最新版本后无需再维护老版本。

    后台服务：则往往持续发布。

   二进制依赖：往往需要同时维护多个版本（因为客户不会都立即升级到最新版）。

2) 是否有较长的发布周期

    注：发布周期指从准备发布到最后公开发布需要多久

3) 协作规模：同一时期内参与提交的人数规模

    注：主要受互相影响的提交者的规模，某些项目历史参与人数非常多但某段时期其实并不多

4) 是否需要兼容代码审核流程

    注：代码审核流程指一个提交要经过许可才能进入目标分支。

5) 是否有持续集成/自动化测试

   注：有持续集成/自动化测试往往意味着提交的质量可以很快被验证（风险可控）

3. 速查表（如何快速选择分支管理模型）

四、主流的分支管理模型

1. 单主干模型 (TBD, Trunk-based development）

主要特点是：所有提交都在单个主干分支上。

具体做法：

1. 所有提交都在主干分支(一般就叫master)上进行。

2. 发布版本时，创建一个临时发布分支(一般叫release），版本发布一段时间后删除该分支。

3. 已发布版本的bug fix, 先提交到主干分支(master)，再cherry-pick到临时发布分支。

不适合的场景：

1）需要长期维护多个发布版本的场景。

      比如，一个中间件先发布了2.x版本，又发布了3.x版本，每个版本都有客户可能长期使用，因此要同时维护(指修复bug)两个版本。

2）需要多个Feature并行开发的场景。

      比如，一个版本同时包含A/B两个Feature，每个Feature都由若干人开发。此时单主干会导致两个Feature在研发期间产生干扰，从而影响效率。

Google/Facebook在大规模使用这种模型。

单主干(TBD)分支模型的示意图：

2. GitFlow模型 （并发分支模型）

主要特点是：对提交进行分类，比如新特性的开发只提交到Feature分支。git-flow 模型中共有 五种分支类型。

适用的场景：

1. 有较长的版本发布周期（几个星期甚至几个月）、长期的版本支持(LTS) 类项目
2. 在发布版本的周期内进行一定需要并行新特、缺陷修复的开发。

1) 五类分支职责

  git-flow 包括 3个临时分支，2个固定分支（长久存在不可删除）

 Master分支

该分支中包含的是可以部署到生产环境中的代码，不允许把未测试或未审查的代码直接提交到 master 分支。

 Develop分支

develop 是一个进行代码集成的分支。当 develop 分支集成了足够的新功能和 bug 修复代码之后，通过创建 Release 分支进行发布。

 Feature分支/ Hotfix分支 / Release分支

这三类分支是对分支职责的细分，分别对应新特性分支/缺陷修复分支/发布分支。

2) GIT-Flow分支流程的示意图

3. 简化的GIT-Flow

主要特点是：将繁复的GIT-Flow模型根据自己的团队需要进行简化。比如，去掉某种分支类型，使其更符合团队当前的需要。这里以一个示例帮您理解这个精简的过程。

1) SaaS类项目分支示例

对于 SaaS服务类项目，通常只有 一个版本用于线上，在这种场景下，可以去除发布分支（release），保留git-fow的四类分支已满足大多数场景，甚至在某些自动化成熟度较高的团队可以将Feature和Hotfix归集为一类。此示例方案包括 1-2个临时分支，2个固定分支。

4. 其他

在行业内，还有两种主流分支模型，Github-Flow 和 Gitlab-Flow。但这两种模式在一定程度上依赖其平台功能，不具有普适性，这里只做简单介绍。

1) Github-Flow

主要特点是：相比 简化的GIT-Flow，GitHub flow 更适用于持续发布且自动化完善的项目。它只使用两类分支，master 和 临时分支。

具体做法：

1. 创建分支，完成相关开发。

2. 创建 Pull Request。

3. 完成代码检查、自动化测试。

4. 将经过验证的代码合并至master。

2) GitLab-Flow

主要特点是：相比 Github-Flow， GitLab Flow 降低对自动化测试的要求，同时增加环境分支，采用"上游优先"原则管理环境分支。如果有需要，也可以创建发布分支并进行维护。

环境分支 设有一个主分支（master），它是所有分支的"上游"，只有上游分支采纳后才能应用到其他环境分支。对于持续发布的项目，比如设立 测试环境(master)，预发环境(pre-production)，生产环境(production)。三个环境分支的上游顺序为，master>pre-production>production。

环境分支流程示意图：

具体做法（示例：两个环境分支，master、production）：

1. 创建分支，完成相关开发。

2. 创建合并到 master 的 Merge Request 。

3. 完成代码检查，将代码合并至master。

4. 部署master环境，完成测试。

5. 创建合并到 production 的 Merge Request。

五、小结

    Git 分支管理模型并没有普遍适用的最佳做法，我们应当针对团队和项目选择合适的分支管理模型。简单来说，在项目开发中使用多个分支会带来额外的管理和维护开销，但是多个分支对于项目的团队合作、新功能开发和发布管理都是有一定好处的。不同的团队和项目应当根据团队人员组成和意愿、项目的发布周期等因素选择最适合的策略，找到最适合团队的管理方式。

参考资料：

1. IBM Developer：Git分支管理最佳实践 https://developer.ibm.com/alert-zh/ 
2. https://martinfowler.com/bliki/FeatureBranch.html
3. https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development
   
4. https://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/
   
5. https://paulhammant.com/2013/03/13/facebook-tbd-take-2/
   
6. https://trunkbaseddevelopment.com/
   
7. https://nvie.com/posts/a-successful-git-branching-model/
   
8. http://scottchacon.com/2011/08/31/github-flow.html
   
9. https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/