1 摘要

本文介绍了两种常用的代码分支模式：特性分支开发模式、主干开发模式，分别阐述了其优缺点和适用环境；同时剖析了 Google 和腾讯采用主干开发模式的背景和决策因素，捎带分享了这 2 个巨头的实践，供读者在技术选型中参考。

2 背景

按之前的写作思路，本文应该叫《Google 工程效能三板斧之三：主干开发》，但我改变了主意，希望能同时提供国内互联网公司的实践，供读者参考，因此文章标题也随之更改。

软件开发过程中，开发人员通过版本管理工具对源码进行存储，追踪目录和文件的修改历史。为了区隔不同状态的源代码，会采用分支进行管理。不同的软件开发模式，对应着不同的分支模式。

软件业界常用的软件分支模式有多种，但本质上可以分为两类：

• 主干开发模式（Trunk Based Development）

• 特性分支开发模式（Feature Branch Development）

3 两种模式的定义及优缺点分析

特性分支开发模式

特性分支开发模式是指为一个或多个特定的需求 / 缺陷 / 任务创建代码分支（branch），在其上完成相应的开发（一般经过增量测试）后，把它合并（merge）到主干 / 集成分支的开发模式。

通常这种分支生命期会持续一段时间，从几天到几周不等，极少数情况甚至以月算。

特性分支开发模式中常用的有 Git-Flow 模式、Github-Flow 模式和 Gitlab-Flow 模式等。这些模式只有细节上的差异，以 Git-Flow 为例：

 优点：

• 特性开发周期宽松：因为生命期可以较长，较大的需求特性可以在宽松的时间内完成再合入主干；

• 分支测试的时间宽松：因为生命期可以较长，可以有较多时间对分支进行测试，甚至手工测试；

 缺点：

• 分支管理复杂：原因在于大量采用代码分支，且来源分支和合入目标分支各异，操作复杂 —— 以上图为例，可以从 master（Tag 1.0.0） 拉出 hotfix 1.0.2 分支，然后合入到 develop 分支，开发阶段结束后合入到 release branches，发布后合入 master，非常复杂，很容易出错；

• 合并冲突多、解决难：分支生命期越长，意味着与主干的代码差异越大，冲突概率越高，冲突的解决难度越大（甚至成为不可能）；

• 迭代速度慢：特性分支生命期长（数天至数周）意味着特性上线速度慢，相应的迭代速度也慢；

• 需要较多测试环境：每个特性分支都需要分配至少 1 个测试环境，且长期占用（有状态）；

 适用环境：

• 对版本迭代速度要求不高

• 测试自动化程度低，或说主要靠人工测试的

主干开发模式

主干开发，是指开发人员直接向主干（习惯上主干分支通常为：trunk 或 master）提交 / 推送代码。通常，开发团队的成员 1 天至少 1 次地将代码提交到主干分支。在到达发布条件时，从主干拉出发布分支（通常为 release），用于发布。若发现缺陷，直接在主干上修复，并根据需要 cherry pick 到对应版本的发布分支。

 流程：

 优点：

• 分支模型简单高效，开发人员易于掌握不容易出现错误操作

• 避免了分支合并、冲突解决的困扰

• 随时拥有可发布的版本

• 有利于持续集成和持续交付

 缺点：

• 基础架构要求高：合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作，因此需要高效的持续集成平台进行把关；

• 自动化测试要求高：需有完备单元测试代码，确保在代码合入主干前能在获得快速和可靠的质量反馈；

• 最好有代码评审：若代码质量要求高，需要配套代码评审（CR）机制，在代码提交到主干时，触发 CR，通过 Peer Review 后才能正式合入；

• 最好有特性开关：主干开发频发合入主干的情况下，特性拆分得很小，可能是半成品特性，需要配套特性开关（Feature Toggle），只有当特性整体开发完才通过灰度发布等手段逐步打开；

 适用环境：

• 对迭代速度要求高，希望需求快速交付上线

• 基础架构强，持续集成工具高效；

• 团队成员习惯 TDD（测试驱动开发），代码自动化测试覆盖率高（至少增量代码的自动化测试覆盖率高）；

4 为什么 Google 和腾讯采用主干开发模式

互联网巨头 Google 大部分业务开发都采用主干开发模式，国内巨头腾讯也在推行主干开发（试点业务团队大部分已经采用）。

他们采用主干开发的原因在于对主干开发的优点有强烈诉求，而且有能力和资源弥补其缺点：

• 都是互联网企业，竞争激烈，因此对迭代速度要求高；

• 基础架构能力强：都能自研强大的持续集成平台，Google 有自研的 Forge，腾讯有自研的蓝盾；

• 自动化测试能力强：都推行 TDD，强调开发负责质量，减少甚至取消手工测试人员（少量必要的手工测试转外包），自动化测试覆盖率高；

• 都有严格的 CR 机制确保代码质量：Google 极其严苛的可读性认证（Readability）在业界已经是标杆，腾讯是国内少有正在采用类似实践的互联网企业。严格的代码可读性认证和根据此标准执行的严格代码评审制度，能有效的保证合入主干的代码质量不会降低。

主干开发的最大优点是：效率和质量，而这 2 者是软件和互联网企业的核心诉求。主干开发的缺点，巨头有能力和资源来填平这些坑。

因此，从 ROI（Ratio of Investment）的角度来看，Google 和腾讯采用主干开发实属必然。

5 美中两巨头的实践

Google 在主干开发的实践

我们在之前的文章提到，Google 的工程效能（也叫研发效能）核心理念只有简单的 3 条：

• 使用单体代码仓库（参考：Google 工程效能三板斧之一：单体代码仓库）

• 使用 Bazel 构建（参考：Google 工程效能三板斧之二：使用 Bazel 构建）

• 主干开发；

其中的第 3 条，就是本文所述内容。

为了保证主干代码的质量，避免出现工程师合入到主干的代码 break 掉主干的情况，Google 采取了以下实践：

• 代码合入事件触发通过持续集成，确保合入到主干的代码经过充分且必要测试；

• 通过 Bazel 实现相关代码（指依赖变更代码的代码）的精准测试；

• 至少 2 个合资格的 reviewer （代码评审人）的 LGTM（Look Good To Me），才允许代码合入主干；

• 合资格的 reviewer 都是在 Google 内部通过 Readability （代码可读性）认证的员工；

腾讯在主干开发的实践

腾讯某 BG 在 2018 年开始的“930 变革”后，在各试点团队推动主干开发（注：并未全公司普遍采用），具体的举措包括：

• 以度量牵引：通过对特性分支）的生命期监控和预警，实现非主干分支的生命期缩短，倒逼开发团队采用主干开发；

• 投大力气统一 BG 内的持续集成工具、开发自动化测试平台；

• 制定了 7 大编程语言的编码规范，并自研代码静态扫描工具；

• 并参考 Google 推行代码可读性（Readability）、可测试性（Testability）认证制度；

• 强力推行 CR （代码评审）制度，确保代码的可读性（命名、代码风格、设计、复杂度）。

 效果：

• 质量提升：代码质量从可测量的维度得到明显提升（代码规范率、单元测试覆盖率）；

• 迭代速度提升：试点团队的迭代周期从 4 周或 2 周提升至 1 周；

• 代码从“私有”变“公有”：通过代码评审制度，提高了代码可读性，使代码从个人拥有（只有写代码的人能看懂），变成团队拥有（整个团队都能看懂）；这一点对于企业非常重要，接手过别人代码的程序们都有感受；

• 代码的自动化测试覆盖率提升明显，为未来的重构构筑了一张安全网；

6 中小企业能参考什么？

中小企业应该选择特性分支开发模式，还是主干开发模式？根据上文，相信大家已经足以自行判断。

有些中小企业的技术决策者非常认可持续集成 / 持续交付的理念，从而更希望采用主干开发，但对于主干开发的缺点（或说弥补缺点的成本）存在顾虑。

对此，我有如下建议：

• 基础架构要求：可以考虑采用开源软件，如持续集成采用 Jenkins、Travis CI、Gitlab CI 等，通过简单部署可以投入使用；同时配合代码静态分析工具（如 SonarQube、CheckStyle），确保代码基本质量过关；

• 自动化测试要求：工具上不存在障碍，现代编程语言（如 java、go、c++）都有内建或第三方的单元测试框架；难点只在于成员的开发习惯，可以通过测试覆盖率工具，以增量覆盖率指标保证新增代码都有完备的自动化测试，从而逐步改变团队的研发文化；

• 代码评审要求：开源的 Git 服务器（如 Gitlab）基本都支持 push hook，配合开源的 Gerrit 等 CR 工具，可以实现在代码推送（push）或 pull request（合入请求）时触发 1 个代码评审请求，实现评审通过后，代码才正式合入的功能；剩下的就是研发文化问题了，需要在团队内部推行代码规范、代码可读性等宣导和教育工作；

• 发布时的特性开关：如果要求不高，可以通过代码 hard code 一个常量作为特性开关；如果要求高，也有开源的特性开关（比如：unleash、piranha、flipper）工具可供选择。参考上述建议，并充分认识到主干开发的成本和困难的情况下，中小企业开发团队也并非不可以考虑主干开发的实践。