多年前，在给一个团队辅导时候，有人问为什么需要代码分支？这让我多少有点诧异。
业界有诸如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）则可以通过配置来实现，避免创建新的分支，从而保持版本的一致性。随着产品的发展，定制需求增加时，产品经理需考虑是否减少定制项或将一些定制特性整合为核心功能。
在尝试主干开发前，团队需考虑是否真正需要它以及它能否解决当前面临的问题。同时，还需确保满足特定的前提条件，并在实施过程中注意以下几点：
• 前提：理解主干开发的优势与劣势、熟悉持续集成流程，避免并行多个版本。• 主干开发的优点包括：• 高发布频率（可达到一周多次）• 团队集中精力于当前版本的开发与集成• 早期解决系统集成问题• 统一测试环境管理• 缺点有：• 发布频率受团队规模限制• 过度依赖功能开关• 不利于定制化产品的开发• 注意事项：• 维持主干稳定性和可用性。• 主要在主干上进行开发，仅在必要时创建分支。• 定期通过持续集成检查主干及发布分支的质量。• 在发布分支中验证测试发现的问题。• 遇到生产环境问题时，先回滚至最近的稳定版本，再按照既定程序修复。一句话，“主干开发-主干发布”更加适合互联网产品、单一产品的主流开发模式；“主干开发-分支发布”没有前者那么激进，对于多客户多版本的商业软件相对比较合适。但是，两者都对主干分支的质量提出了更高的要求。
选择适合自己团队更好交付的分支策略正如开头说的，分支模型看似是个很小的事情，实际研发过程中，和周边很多因素有关系（如下图）。
忘掉那些主流的分支模型，只要掌握了上述四种基本的分支模型，吃透里面的内涵，就可以定义适合团队协作交付的好的分支策略。
最后，让AI编了一个顺口溜，结束本次的分享。
• 稳定快速两难全，分支隔离求平安。• 分支开多维护烦，分久必合合并难。• 冲突少，勤变基，分支尽量要少开。• 需求关联做得好，变更范围一目了然。• 测试工作量减少，每日集成是底线！画板画板