为什么需要代码分支？代码分支怎么设计？

DevOps在路上

发布于 2025-12-24 16:33:59

2460

多年前，在给一个团队辅导时候，有人问为什么需要代码分支？这让我多少有点诧异。 业界有诸如TBD、GitHub Flow、git-flow , gitlab-flow以及 AoneFlow等分支管理策略, 它们都是在具体的实践场景下演化而来的。

本文将从“为什么需要代码分支”开始，有简入深，探究分支的本质，设计适合你团队的分支。

为什么需要代码分支？

分支开发往小了说，是版本管理的一种方式。往大了说，它与产品发布、研发团队间协作、集成方式，服务器测试环境管理等密切有关。

首先记住一句话，开分支是为了解决“稳定”和“快速发布”的矛盾，既要现有功能的“稳定”又要“快速”发布新功能**。为了保证现有功能的稳定，那么就要“隔离”，让“现有的”和“新开发-不稳定的”保持隔离。

“稳定”和“快速发布”引起的“代码合并冲突”

但是“现有的”和“新开发的”最终要一起发布，于此同时，多个“新开发的”特性有会容易引起冲突。

从基本的分支模型说起

一般把Trunk（Master）称之为主干，Branch称之为分支，但是Trunk永远只有一个。对应线上的版本，我们用称之为发布分支的Release来管理。Release分支上永远是稳定版本。

• 对于主干开发来说，代码所经历的过程是从开发人员PC到Trunk到Branch最后到Release 的过程。
• 根据代码交付的路径不同，另一种交付模式“分支开发”，分支开发的过程则是从开发人员的PC到Branch到Trunk最后到Release的过程。

正是这中间两步的差异，造就了两个开发模式之间的天壤之别，而彼此的优缺点也大不相同。

分支开发-主干发布

• 优点：多个功能使用feature并行开发，互不影响，及时有冲突也可以快速解决
• 缺点：如果feturea分支间代码有交叉，容易导致合并冲突；单独对某个feature分支的测试，不能完全实现集成测试，浪费资源，并未真正实施集成测试

画板

该分支模型衍生出来的典型示例如下，就是我们熟悉的git-flow分支模型（多分支并行开发，单一发布分支）。

适用场景：网站、SAAS服务、APP 版本是一直滚动迭代的。

团队人数的增多，可能要处理好：

• 新人适应规范，代码评审
• 功能延期；
• 实验性探索；

实际使用中，为了方便测试与发布准备，单一发布分支中间会增加几个分支用作缓冲，例如先使用一个test分支用作合并feature并先行测试验证。测试验证过后，再合并到staging分支做发布准备。发布实际完成以后再合入main。

本来该模型主要用于saas系统的版本迭代，不过在实践中，看到很多非saas产品团队特别习惯使用这种，主要原因就是因为开分支做“缓冲”用，来源于对自己产品质量的不自信，怕污染主干master。

分支开发-分支发布

• 优点：常见的一种代码开发方式。多个功能使用feature分支并行开发，互不影响可以选择指定的feature分支进行代码的发布，不会波及其他的变更。
• 缺点：feature分支发布后容易忘记合并回master主干。feature分支代码测试，需要单独建立测试流水线，浪费资源，而且并未真正实施项目集成测试

画板

主干开发-分支发布

• 优点：主干开发过程中，分支合并工作量较少
• 缺点：其实也算不上缺点，新功能代码在主干（master）开发，对主干代码的质量要求比较高

画板

如下图，展示了单一分支开发，发布后创建分支的典型示例。

适用场景：2B类商业软件，客户多，既要保证主线演进，也要兼顾交付版本维护

软件发布后，开发团队需要处理的两项主要工作

1. 跟踪维护已发布的代码，为其修复缺陷
- • 使用分支来跟踪已发布的代码并进行缺陷修补。
- • 使用TAG（标签） 来标记发布的代码版本，作为基准线。
2. 继续进行新版本的开发
- • 新版本的功能开发仍然在主干（如 main分支）上进行。

注意：当一项改动（例如一个缺陷的修复）需要应用到多个已发布的分支时，在某个分支修复后，需要将对应的一个或多个提交合并到其他受影响的分支。可以使用代码库的指令（例如 git cherry-pick）来完成此操作。有时，如果代码差异较大，可能需要人工介入进行手动修复。

主干开发-主干发布

• 优点：效率最高的一种项目开发方式。主干集成测试，代码冲突易于提前发现主干代码安全稳定，每次测试通过后，都可以随时发布。
• 缺点：新功能代码在master主干上开发，若主干代码达不到稳定的标准，不可以进行项目发布。master上主干开发有先后，有未完成的功能但又需要发布时，需要能隐藏未完成部分。

画板

如下图，展示了一个开源项目的分支图，接近一条直线。在项目初期以及开源项目比较常见（省去了维护分支的成本），仅使用一个分支协作，提交代码，对特别版本进行标记TAG。

该模型是业界比较推崇的，但依赖基础设施和自动化的保障，以及协作成员的代码质量，在实际的研发活动中，受制于团队水平以及交付集成限制，较少见到。

小结

针对上面的四种模型，个人更推崇后两种，过多的分支和不够完整的少频次集成，并不是好事。这里重点再分析下后两种。

主干开发-分支发布

如下图，从代码的路径我们可以看到多个开发人员的代码的汇聚点在Trunk上，这就是主干开发第一个显著的特点，即所有开发人员的代码都是基于同一套代码进行开发。开发人员每天都在这个主干上签入签出他们的代码，不断地集成，测试和修复，直到计划的发布的功能被实现的时候，再从这个版本打一个Tag，然后拉一个测试分支发布到系统测试环境。系统测试人员对测试分支进行系统测试。而同时开发人员则继续在主干上开发新的功能。系统测试环境发现的缺陷，会在系统测试分支上被修复，修复后立刻同步到Trunk上。经过系统测试的版本接下来会发布到生产环境。而此时开发人员可能正在准备第二个版本的系统测试交付。

主干开发-分支发布

主干开发-主干发布

主干开发模式极大消除了系统集成风险，让原本痛苦的系统集成，在开发阶段的时候就无时无刻的发生。这种模式把敏捷的持续集成实践方法发挥到了极致。这就使得系统的潜在可交付产品（Potential Shippable Product）的成功率大大被提高了。

与Scrum中的迭代潜在可交付产品略有不同的是，Scrum的迭代交付是在迭代内完整功能的交付，如果不能在本迭代做完的功能，则建议拆分地端到端更为细小或者放入下一个迭代来完成。直到可交付的功能可以满足一定业务需要时，才进行系统测试和发布。当然在迭代过程中进行系统测试也不是坏事，只要有自动化或者人力保障（关于迭代内回归测试对于刚转型的scrum团队来说，永远是抹不掉的痛）。因此Scrum的发布周期和迭代长度往往是1：1或者1:N的关系。

主干开发-主干发布

回到主干开发，它将要交付的版本并不包含所有完整，开发人员需要通过功能开关来屏蔽不希望用户看到的功能。只有那些实现了完整业务的功能才会被展现在用户面前。这样做看上去很不“安全“，但是却解决了功能不能拆分或不能组装而无法完整业务发布、不能发布的问题。

正因为这样，主干开就发变得“准”时可发布。它可选择的发布窗口期可以不再是迭代的倍数，而是在迭代内也可以，甚至有团队做到每天一发布

主干开发的优缺点

主干开发是指所有开发者在同一主干上进行代码的提交与更新。这种方式在复杂环境中能提前发现并解决问题，但不太适合高度定制化的产品

对于需要定制化的产品，可以将其分为核心功能和定制功能两部分。核心功能适合使用主干开发；而定制功能（如更改产品首页Logo）则可以通过配置来实现，避免创建新的分支，从而保持版本的一致性。随着产品的发展，定制需求增加时，产品经理需考虑是否减少定制项或将一些定制特性整合为核心功能。

在尝试主干开发前，团队需考虑是否真正需要它以及它能否解决当前面临的问题。同时，还需确保满足特定的前提条件，并在实施过程中注意以下几点：

• 前提：理解主干开发的优势与劣势、熟悉持续集成流程，避免并行多个版本。
• 主干开发的优点包括：
- • 高发布频率（可达到一周多次）
- • 团队集中精力于当前版本的开发与集成
- • 早期解决系统集成问题
- • 统一测试环境管理
• 缺点有：
- • 发布频率受团队规模限制
- • 过度依赖功能开关
- • 不利于定制化产品的开发
• 注意事项：
- • 维持主干稳定性和可用性。
- • 主要在主干上进行开发，仅在必要时创建分支。
- • 定期通过持续集成检查主干及发布分支的质量。
- • 在发布分支中验证测试发现的问题。
- • 遇到生产环境问题时，先回滚至最近的稳定版本，再按照既定程序修复。