GIT分支管理最佳实践
一、目的
本文对行业内 主流分支管理模型 进行分析介绍，帮助读者快速找到适合自己的分支管理模型。
二、目标受众
本文假定读者熟悉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 模型中共有 五种分支类型。
适用的场景：
-
有较长的版本发布周期（几个星期甚至几个月）、长期的版本支持(LTS) 类项目 -
在发布版本的周期内进行一定需要并行新特、缺陷修复的开发。
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 分支管理模型并没有普遍适用的最佳做法，我们应当针对团队和项目选择合适的分支管理模型。简单来说，在项目开发中使用多个分支会带来额外的管理和维护开销，但是多个分支对于项目的团队合作、新功能开发和发布管理都是有一定好处的。不同的团队和项目应当根据团队人员组成和意愿、项目的发布周期等因素选择最适合的策略，找到最适合团队的管理方式。
参考资料：
IBM Developer：Git分支管理最佳实践 https://developer.ibm.com/alert-zh/ https://martinfowler.com/bliki/FeatureBranch.html https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development
https://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/
https://paulhammant.com/2013/03/13/facebook-tbd-take-2/
https://trunkbaseddevelopment.com/
https://nvie.com/posts/a-successful-git-branching-model/
http://scottchacon.com/2011/08/31/github-flow.html
https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/
SHAREit技术团队