在阿里，我们如何管理代码分支？

点击关注 InfoQ，置顶公众号

接收程序员的技术早餐

作者｜林帆

编辑｜小智

写在前面

在阿里内部，流行着许多有意思的工程实践。有些实践通过工具和流程嵌在集团的大环境里，外界不容易复制，有些实践则是流露在大家的日常习惯里，被默默的遵守。比如分支管理这件事，其实属于工具和习惯各占一半，并且颇有阿里特色的成分，适合作为一个例子。阿里有很多的研发团队，不同事业部使用的发布流程、分支策略并非整齐划一，但总体上看是比较规整的。其中有一种主流的发布模式以及对应的分支使用方式，称为“AoneFlow”。这套工作模式思路独特，在阿里以外的地方并不多见。本文围绕这些实践，聊一聊分支管理的话题。

细数分支模式

说到分支管理模式，我们最耳熟能详的莫过于 TrunkBased 和 GitFlow。

TrunkBased 模式 是持续集成思想所崇尚的工作方式，它由单个主干分支和许多发布分支组成，每个发布分支在特定版本的提交点上从主干创建出来，用来进行上线部署和 Hotfix。在 TrunkBased 模式中，没有显性的特性分支。当然实际上 Git 的分布式特征天生允许每个人有本地分支，TrunkBased 也并非排斥短期的特性分支存在，只不过在说这种模式的时候，大家通常都不会明确强调它罢了。

虽然近年来有许多不错的案例，但 TrunkBased 模式并没有一统天下。它的缺点比较明显，太多的团队同时工作在主干上，到发布的时候就可能出现灾难（尤其是多版本并行开发的情况）。弥补的措施是 FeatureToggle 以及频繁的集成和足够的测试覆盖，这对开发团队的能力提出了比较高的要求。目前 TrunkBased 模式主要用在不需要同时维护多个历史版本的 SaaS 型项目，特别是经过微服务改造的各种小型服务上。

TrunkBased 模式有两种常见演进版本。OneFlow 模式 参考了 TrunkBased 的许多思想，对操作流程做了更严格的定义，增加了 Hotfix 分支等内容。多主干模式（通常是双主干，固定的开发分支和固定的发布分支），算是 TrunkBased 采用固定发布分支的特例，在 提升团队的微服务落地能力 这篇文章里介绍过，不再赘述。

GitFlow 模式 是若干模式的集大成者，包含一个主干分支、一个开发分支、许多的特性分支、许多的发布分支和 Hotfix 分支，以及许多繁琐的合并规则。它有一个 Git 插件，不过早就没人维护了。由于对每个阶段的每项操作定义十分明确，它曾经是很多重视流程的企业眼里的香馍馍。但它使用起来并不是很容易，大量的合并冲突和对集成测试不友好也是它被诟病最多的地方。

对，还有 GithubFlow 模式，不过这种策略无非是在 TrunkBased 的基础上，增加了个人仓库和 Pull Request 合并代码的操作，与在同一个仓库里增加个人分支的做法类似，从实用的意义来说，它更合适分布式团队。GithubFlow 也有演进版本，例