管理源代码分支的模式

源代码分支

创建一个副本并记录对该副本的所有更改。

如果几个人在同一个代码库上工作，他们很快就会无法在同一个文件上工作。如果我想运行编译，而我的同事正在输入表达式，那么编译将失败。我们不得不互相喊叫：“我正在编译，不要改变任何东西”。即使只有两个人，这也难以维持，而对于一个更大的团队来说，这将是不可理解的。

对此的简单答案是，每个开发人员都获取代码库的副本。现在我们可以轻松地处理自己的功能，但出现了一个新问题：当我们完成后，如何将我们的两个副本合并回来？

源代码控制系统使此过程变得更加容易。关键是它将对每个分支所做的每次更改都记录为提交。这不仅可以确保没有人忘记他们对 `utils.java` 所做的小改动，记录更改还可以更容易地执行合并，尤其是在多个人更改了同一个文件时。

这导致了我将在本文中使用的分支定义。我将分支定义为对代码库的特定提交序列。分支的头部或尖端是该序列中的最新提交。

那是名词，但也有动词“分支”。我的意思是创建一个新分支，我们也可以将其视为将原始分支分成两个分支。当一个分支的提交应用于另一个分支时，分支就会合并。

我使用的“分支”定义与我观察到的大多数开发人员谈论它们的方式相对应。但是源代码控制系统倾向于以更特殊的方式使用“分支”。

我可以用一个现代开发团队中的常见情况来说明这一点，该团队将其源代码保存在共享的 git 存储库中。一位名叫 Scarlett 的开发人员需要进行一些更改，因此她克隆了该 git 存储库并检出了 master 分支。她进行了一些更改，并提交回她的 master 分支。同时，另一位开发人员，我们称她为 Violet，将存储库克隆到她的桌面上并检出 master 分支。Scarlett 和 Violet 是在同一个分支上工作还是在不同的分支上工作？他们都在“master”上工作，但他们的提交彼此独立，并且在将更改推回共享存储库时需要合并。如果 Scarlett 决定不确定她所做的更改，因此她标记了最后一次提交并将她的 master 分支重置为 origin/master（她从共享存储库克隆的最后一次提交），会发生什么情况？

根据我之前给出的分支定义，Scarlett 和 Violet 正在不同的分支上工作，彼此独立，也与共享存储库上的 master 分支独立。当 Scarlett 用标签搁置她的工作时，根据我的定义，它仍然是一个分支（她很可能认为它是一个分支），但在 git 的说法中，它是一条带标签的代码行。

使用像 git 这样的分布式版本控制系统，这意味着每当我们进一步克隆存储库时，我们也会获得额外的分支。如果 Scarlett 克隆她的本地存储库以将其放在笔记本电脑上以便回家路上使用，那么她就创建了第三个 master 分支。在 GitHub 中进行 fork 时也会出现同样的效果——每个 fork 的存储库都有自己的一组额外分支。

当我们遇到不同的版本控制系统时，这种术语上的混淆会变得更糟，因为它们对什么是分支都有自己的定义。Mercurial 中的分支与 git 中的分支完全不同，后者更接近于 Mercurial 的书签。Mercurial 还可以使用未命名的头部进行分支，并且 Mercurial 用户经常通过克隆存储库来进行分支。

所有这些术语上的混淆导致一些人避免使用这个术语。这里一个更有用的通用术语是代码线。我将代码线定义为代码库的特定版本序列。它可以以标签结束，可以是分支，也可以丢失在 git 的 reflog 中。您会注意到我的分支和代码线定义之间存在着惊人的相似之处。代码线在很多方面都是更有用的术语，我确实使用它，但在实践中它并没有被广泛使用。因此，在本文中，除非我是在 git（或其他工具）术语的特定上下文中，否则我将交替使用分支和代码线。

这种定义的结果是，无论您使用什么版本控制系统，每个开发人员在对其自己机器上的工作副本进行本地更改后，至少都有一条个人代码线。如果我克隆一个项目的 git 存储库，检出 master 分支，并更新一些文件——即使在我提交任何内容之前，这都是一条新的代码线。类似地，如果我创建 subversion 存储库主干的自己的工作副本，那么该工作副本就是它自己的代码线，即使没有涉及 subversion 分支。

主线

一个单一的、共享的、充当产品当前状态的分支

主线是一个特殊的代码线，我们将其视为团队代码的当前状态。每当我想开始一项新的工作时，我都会从主线中提取代码到我的本地仓库中开始工作。每当我想与团队中的其他人共享我的工作时，我会用我的工作更新主线，最好使用我稍后将讨论的主线集成模式。

不同的团队对这个特殊分支使用不同的名称，这通常受到所使用的版本控制系统的约定的影响。git 用户通常称之为“master”，subversion 用户通常称之为“trunk”。

我必须在这里强调，主线是单一、共享的代码线。当人们在 git 中谈论“master”时，他们可能指的是几个不同的东西，因为每个仓库克隆都有自己的本地 master。通常，这样的团队都有一个中央仓库——一个共享仓库，它充当项目的单一记录点，并且是大多数克隆的来源。从头开始一项新的工作意味着克隆该中央仓库。如果我已经有一个克隆，我会先从中央仓库中拉取 master，以便它与主线保持同步。在这种情况下，主线是中央仓库中的 master 分支。

当我在开发我的功能时，我有我自己的个人开发分支，它可能是我本地的 master，或者我可以创建一个单独的本地分支。如果我在这上面工作了一段时间，我可以通过定期拉取主线的更改并将它们合并到我的个人开发分支中来保持与主线的同步。

类似地，如果我想创建一个新版本的产品来发布，我可以从当前的主线开始。如果我需要修复错误以使产品足够稳定以供发布，我可以使用发布分支。

健康分支

在每次提交时，执行自动检查，通常是构建和运行测试，以确保分支上没有缺陷

由于主线具有这种共享的、已批准的状态，因此保持其稳定状态非常重要。同样是在 21 世纪初，我记得我曾与另一个组织的一个团队交谈，该组织以每天构建其每种产品而闻名。这在当时被认为是一种相当先进的做法，该组织也因此受到称赞。在这些文章中没有提到的是，这些每日构建并不总是成功。事实上，发现团队的每日构建已经几个月没有编译成功的情况并不少见。

为了解决这个问题，我们可以努力保持分支的健康——这意味着它可以成功构建，并且软件运行时几乎没有错误。为了确保这一点，我发现编写自测试代码至关重要。这种开发实践意味着，在我们编写生产代码时，我们还会编写一套全面的自动化测试，以便我们可以确信，如果这些测试通过，那么代码中就没有错误。如果我们这样做，那么我们可以通过每次提交都运行一个构建来保持分支的健康，这个构建包括运行这个测试套件。如果系统编译失败，或者测试失败，那么我们的首要任务是在对该分支进行任何其他操作之前修复它们。这通常意味着我们“冻结”分支——除了修复以使其再次健康之外，不允许对其进行任何提交。

在提供足够信心以确保健康的测试程度上存在着一种张力。许多更彻底的测试需要很长时间才能运行，从而延迟了对提交是否健康的反馈。团队通过在部署管道上将测试分成多个阶段来处理这个问题。这些测试的第一阶段应该运行得很快，通常不超过十分钟，但仍然要相当全面。我将这样的套件称为提交套件（尽管它通常被称为“单元测试”，因为提交套件通常主要是单元测试）。

理想情况下，应该对每次提交都运行所有测试。但是，如果测试很慢，例如需要将服务器浸泡几个小时的性能测试，那就不切实际了。如今，团队通常可以构建一个可以在每次提交时运行的提交套件，并尽可能频繁地运行部署管道的后期阶段。

代码无错误运行不足以说明代码是好的。为了保持稳定的交付速度，我们需要保持代码的内部质量。一种流行的方法是使用集成前审查，尽管正如我们将看到的，还有其他选择。

主线集成

开发人员通过从主线拉取、合并以及（如果健康）推回主线来集成他们的工作

主线清晰地定义了团队软件的当前状态。使用主线最大的好处之一是它简化了集成。如果没有主线，那就是我上面描述的与团队中的每个人协调的复杂任务。然而，使用主线，每个开发人员都可以自己进行集成。

我将通过一个例子来说明这是如何工作的。一位我称之为 Scarlett 的开发人员通过将主线克隆到她自己的仓库中来开始一些工作。使用 git，如果她还没有中央仓库的克隆，她将克隆它并检出 master 分支。如果她已经有了克隆，她将从主线拉取到她的本地 master 中。然后，她可以在本地工作，将提交提交到她的本地 master 中。

当她工作时，她的同事 Violet 将一些更改推送到主线上。由于她在自己的代码线中工作，Scarlett 在处理自己的任务时可能没有注意到这些更改。

在某个时候，她到达了一个她想要集成的点。这的第一部分是将主线的当前状态获取到她的本地 master 分支中，这将拉入 Violet 的更改。当她在本地 master 上工作时，提交将显示在 origin/master 上，作为一个单独的代码线。

现在，她需要将她的更改与 Violet 的更改合并。有些团队喜欢通过合并来做到这一点，而另一些团队则喜欢通过变基来做到这一点。一般来说，人们在谈论将分支合并在一起时，无论他们是实际使用 git 合并还是变基操作，都会使用“合并”一词。我将遵循这种用法，所以除非我实际上在讨论合并和变基之间的区别，否则请将“合并”视为可以使用其中任何一种实现的逻辑任务。

关于是使用普通合并、使用还是避免快进合并，还是使用变基，还有很多其他的讨论。这超出了本文的范围，尽管如果人们给我发送足够的 Tripel Karmeliet，我可能会写一篇关于这个问题的文章。毕竟，如今“有来有往”才是王道。

如果 Scarlett 幸运的话，合并 Violet 的代码将是一个干净的合并，如果不是，她将不得不处理一些冲突。这些可能是文本冲突，其中大多数源代码控制系统可以自动处理。但是，语义冲突要难处理得多，这就是自测试代码非常方便的地方。（由于冲突可能会产生大量的工作，并且总是会带来大量工作的风险，我用一块令人担忧的黄色来标记它们。）

此时，Scarlett 需要验证合并后的代码是否满足主线的健康标准（假设主线是一个健康分支）。这通常意味着构建代码并运行构成主线提交套件的任何测试。即使这是一个干净的合并，她也需要这样做，因为即使是一个干净的合并也可能隐藏语义冲突。提交套件中的任何失败都应该纯粹是由于合并造成的，因为两个合并父级都应该是绿色的。知道这一点应该有助于她追踪问题，因为她可以查看差异以寻找线索。

通过这个构建和测试，她已经成功地将主线拉取到她的代码线中，但是——这一点很重要，而且经常被忽视——她还没有完成与主线的集成。要完成集成，她必须将她的更改推送到主线中。除非她这样做，否则团队中的其他人将与她的更改隔离——本质上是不集成。集成既是拉取又是推送——只有在 Scarlett 推送之后，她的工作才与项目的其余部分集成。

如今，许多团队要求在将提交添加到主线之前进行代码审查步骤——我称之为集成前审查的模式，稍后将讨论。

有时，在 Scarlett 可以推送她的代码之前，其他人会先将代码集成到主线。在这种情况下，她必须再次拉取并合并代码。通常，这只是偶尔出现的问题，无需进一步协调即可解决。我见过一些构建时间较长的团队使用集成令牌，以便只有持有令牌的开发人员才能进行集成。但近年来，随着构建时间的缩短，我很少听到这种做法。

特性分支

将一项特性的所有工作都放在其自己的分支上，并在特性完成后集成到主线中。

使用特性分支，开发人员在开始一项特性的工作时会打开一个分支，继续处理该特性直到完成，然后将其集成到主线中。

例如，让我们以 Scarlett 为例。她将负责添加本地销售税收集功能到他们的网站。她从当前稳定的产品版本开始，将主线拉取到她的本地存储库中，然后创建一个从当前主线尖端开始的新分支。她在该特性上工作所需的时间，对该本地分支进行一系列提交。

她可能会将该分支推送到项目存储库，以便其他人可以查看她的更改。

在她工作期间，其他提交会进入主线。因此，她可能会不时地从主线拉取代码，以便了解那里的任何更改是否可能会影响她的特性。

请注意，这与我上面描述的集成不同，因为她没有将代码推送到主线。此时，只有她能看到她的工作，其他人看不到。

有些团队希望确保所有代码（无论是否已集成）都保存在中央存储库中。在这种情况下，Scarlett 会将她的特性分支推送到中央存储库。这也将允许其他团队成员查看她的工作内容，即使它尚未集成到其他人的工作中。

当她完成该特性的工作后，她将执行主线集成，将该特性合并到产品中。

如果 Scarlett 同时处理多个特性，她将为每个特性打开一个单独的分支。

持续集成

开发人员一旦有可以共享的健康提交，就会立即进行主线集成，通常不到一天的工作量

一旦团队体验到高频集成既更高效又更轻松，那么自然要问的问题是“我们可以多频繁地进行集成？”特性分支意味着变更集的大小有一个下限 - 不能小于一个 cohesive 特性。

持续集成应用了不同的集成触发器 - 每当您在功能方面取得一定进展并且您的分支仍然健康时，您就可以进行集成。不要求功能完整，只要求对代码库进行了有价值的更改。经验法则是“每个人每天都提交到主线”，或者更准确地说：*您的本地存储库中永远不应该有超过一天的工作未集成*。在实践中，大多数持续集成实践者每天都会集成多次，他们乐于集成一小时或更短时间的工作量。

使用持续集成的开发人员需要习惯于使用部分构建的功能来达到频繁的集成点。他们需要考虑如何在不公开运行系统中部分构建的功能的情况下做到这一点。通常这很容易：如果我正在实现一个依赖优惠券代码的折扣算法，并且该代码尚未出现在有效列表中，那么即使我的代码已投入生产，它也不会被调用。同样，如果我正在添加一项功能，询问保险索赔人是否是吸烟者，我可以构建和测试代码背后的逻辑，并通过将提出该问题的 UI 留到构建功能的最后一天来确保它不会在生产中使用。通过最后连接关键接口来隐藏部分构建的功能通常是一种有效的技术。

如果无法轻松隐藏部分功能，我们可以使用功能标志。除了隐藏部分构建的功能外，此类标志还允许将功能选择性地公开给一部分用户 - 这对于新功能的缓慢推出通常很方便。

集成部分构建的功能尤其让那些担心主线中存在错误代码的人感到担忧。因此，使用持续集成的人还需要自测代码，以便确信在主线中包含部分构建的功能不会增加出现错误的可能性。使用这种方法，开发人员在编写部分构建的功能代码时为其编写测试，并将功能代码和测试一起提交到主线（可能使用测试驱动开发）。

就本地存储库而言，大多数使用持续集成的人都不会费心使用单独的本地分支来工作。通常可以直接提交到本地主服务器并在完成后执行主线集成。但是，如果开发人员愿意，在功能分支中打开并在那里完成工作，然后定期集成回本地主服务器和主线是完全可以的。功能分支和持续集成之间的区别不在于是否存在功能分支，而在于开发人员何时与主线集成。

集成前审查

在接受提交之前，对主线的每次提交都要进行同行评审。

长期以来，代码审查一直被鼓励作为一种提高代码质量、改进模块化、可读性和消除缺陷的方法。尽管如此，商业组织经常发现很难将其融入软件开发工作流程中。然而，开源世界广泛接受了这样一种理念，即在接受对项目的贡献之前应该对其进行审查，并且这种方法近年来在开发组织中得到了广泛的传播，尤其是在硅谷。像这样的工作流程特别适合 GitHub 的拉取请求机制。

当 Scarlett 完成了她希望集成的一大块工作时，这样的工作流程就开始了。就像她在成功构建后进行主线集成一样（假设她的团队是这样做的），在她推送到主线之前，她会将她的提交发送出去进行审查。然后，团队中的其他成员，比如 Violet，会对提交进行代码审查。如果她对提交有问题，她会提出一些意见，然后双方会来回讨论，直到 Scarlett 和 Violet 都满意为止。只有当他们完成后，提交才会被放到主线上。

集成前审查随着开源的兴起而流行起来，它非常适合于由忠诚的维护者和偶尔的贡献者组成的组织模式。它们允许维护者密切关注任何贡献。它们也与功能分支很好地结合在一起，因为完成的功能标志着进行此类代码审查的明确点。如果您不确定贡献者是否会完成一项功能，为什么要审查他们的部分工作？最好等到功能完成。这种做法也在大型互联网公司中广泛传播，谷歌和 Facebook 都构建了特殊的工具来帮助这项工作顺利进行。

培养及时进行集成前审查的纪律非常重要。如果开发人员完成了一些工作，然后又去做其他事情几天，那么当审查意见回来时，这项工作就不再是他们脑海中的首要任务了。对于已完成的功能来说，这令人沮丧，但对于部分完成的功能来说，情况要糟糕得多，因为在审查得到确认之前，可能很难取得进一步的进展。原则上，可以使用持续集成进行集成前审查，实际上也是可能的——谷歌遵循这种方法。但是，尽管这是可能的，但它很困难，而且相对少见。集成前审查和功能分支是更常见的组合。

发布分支

一个只接受为稳定准备发布的产品版本而提交的分支。

一个典型的发布分支将从当前主线复制，但不允许添加任何新功能。主要开发团队继续向主线添加此类功能，这些功能将在未来的版本中获得。在发布分支上工作的开发人员只专注于消除任何阻止发布到生产环境的缺陷。对这些缺陷的任何修复都在发布分支上创建并合并到主线。一旦没有更多需要处理的错误，该分支就可以进行生产发布了。

尽管发布分支上修复工作的范围（希望）比新功能代码要小，但随着时间的推移，将它们合并回主线变得越来越困难。分支不可避免地会发生分歧，因此随着越来越多的提交修改主线，将发布分支合并到主线变得更加困难。

以这种方式将提交应用于发布分支的一个问题是，很容易忽略将它们复制到主线，特别是当由于分支分歧而变得更加困难时。由此产生的回归是非常尴尬的。因此，有些人倾向于在主线上创建提交，并且只有在它们在那里工作后才将它们挑选到发布分支中。

**挑选**是指将提交从一个分支复制到另一个分支，但分支没有合并。也就是说，只复制了一个提交，而不是自分支点以来的先前提交。在这个例子中，如果我将 F1 合并到发布分支中，那么这将包括 M4 和 M5。但是挑选只获取 F1。挑选可能无法干净地应用于发布分支，因为它可能依赖于在 M4 和 M5 中所做的更改。

在主线上编写发布修复的缺点是，许多团队发现这样做更难，并且在主线上以一种方式修复它并在发布之前必须在发布分支上重新工作是令人沮丧的。当存在发布时间的进度压力时，尤其如此。

一次只在生产环境中使用一个版本的团队只需要一个发布分支，但有些产品会在生产环境中使用多个版本。运行在客户设备上的软件只有在客户希望升级时才会升级。许多客户不愿意升级，除非他们有引人注目的新功能，因为他们已经被失败的升级所困扰。然而，这些客户仍然希望修复错误，特别是如果这些错误涉及安全问题。在这种情况下，开发团队会为仍在使用的每个版本保留发布分支，并根据需要对其应用修复程序。

随着开发的进行，将修复程序应用于旧版本变得越来越困难，但这通常是做生意的成本。只有鼓励客户经常升级到最新版本才能缓解这种情况。保持产品的稳定性对此至关重要，一旦被烧伤，客户将不愿意再次进行不必要的升级。

（我听到的其他发布分支术语包括：“发布准备分支”、“稳定分支”、“候选分支”和“强化分支”。但“发布分支”似乎是最常见的。）

成熟度分支

一个分支，其头部标记着代码库成熟度级别的最新版本。

团队通常想知道源代码的最新版本是什么，这一事实可能会因具有不同成熟度级别的代码库而变得复杂。QA 工程师可能希望查看产品的最新 staging 版本，调试生产故障的人员希望查看最新的生产版本。

成熟度分支提供了一种执行此跟踪的方法。这个想法是，一旦代码库的某个版本达到一定程度的准备就绪，就将其复制到特定的分支中。

考虑一个用于生产环境的成熟度分支。当我们准备发布生产版本时，我们会打开一个发布分支来稳定产品。一旦准备就绪，我们将其复制到一个长期运行的生产分支。我认为这是一种复制而不是合并，因为我们希望生产代码与在上游分支上测试的代码完全相同。

成熟度分支的吸引力之一是，它清楚地显示了发布工作流程中达到该阶段的代码的每个版本。因此，在上面的示例中，我们只希望在生产分支上进行一次提交，该提交结合了提交 M1-3 和 F1-2。有一些 SCM-jiggery-pokery 可以实现这一点，但在任何情况下，这都会丢失与主线上细粒度提交的链接。这些提交应该记录在提交消息中，以帮助人们以后跟踪它们。

成熟度分支通常以发布流程中相应阶段的名称命名。因此，诸如“生产分支”、“staging 分支”和“QA 分支”之类的术语。偶尔我会听到人们将生产成熟度分支称为“发布分支”。

变体：长生命周期发布分支

我可以将其视为发布分支模式的一种变体，它将其与发布候选版本的成熟度分支相结合。当我们希望进行发布时，我们将主线复制到此发布分支中。与每个版本的发布分支一样，提交只会在发布分支上进行，以提高稳定性。这些修复程序也会合并到主线中。我们在发布时对其进行标记，并且当我们想要进行另一个发布时，可以再次复制主线。

提交可以按原样复制，这在成熟度分支中更为典型，也可以合并。如果合并，我们必须小心，确保发布分支的头部与主线的头部完全匹配。一种方法是在合并之前恢复已应用于主线的所有修复程序。一些团队还会在合并后压缩提交，以确保每个提交都代表一个完整的发布候选版本。（发现这很棘手的人有充分的理由更喜欢为每个版本剪切一个新分支。）

这种方法只适用于在生产环境中只有一个版本的產品。

团队喜欢这种方法的一个原因是，它可以确保发布分支的头部始终指向下一个发布候选版本，而无需挖掘最新发布分支的头部。但是，至少在 git 中，我们可以通过拥有一个“发布”分支名称来实现相同的效果，该分支名称在团队剪切新发布分支时使用硬重置移动，并在旧发布分支上留下一个标签。

环境分支

通过应用源代码提交将产品配置为在新环境中运行。

软件通常需要在不同的环境中运行，例如开发人员的工作站、生产服务器，以及可能还有各种测试和 staging 环境。通常，在这些不同的环境中运行需要进行一些配置更改，例如用于访问数据库的 URL、消息系统的位置以及关键资源的 URL。

环境分支是一个分支，其中包含应用于源代码以重新配置产品以在不同环境中运行的提交。我们可能在主线上运行版本 2.4，现在希望在我们的 staging 服务器上运行它。我们通过从版本 2.4 开始剪切一个新分支来做到这一点，应用适当的环境更改，重建产品，并将其部署到 staging 环境。

更改通常是手动应用的，但如果负责的人员熟悉 git，他们可以从早期分支中挑选更改。

环境分支模式通常与成熟度分支结合使用。长期存在的 QA 成熟度分支可能包括对 QA 环境的配置调整。然后，合并到此分支将获取配置更改。类似地，长期存在的发布分支可能包括这些配置更改。

修复分支

用于捕获修复紧急生产缺陷的工作的分支。

如果生产环境中出现严重错误，则需要尽快修复。处理此错误的工作将比团队正在进行的任何其他工作具有更高的优先级，并且任何其他工作都不应减慢此修复程序的工作速度。

修复工作需要在源代码管理中完成，以便团队可以正确记录并协作完成。他们可以通过在最新发布的版本处打开一个分支并在该分支上应用任何修复程序的更改来做到这一点。

一旦将修复程序应用于生产环境，并且每个人都有机会睡个好觉，就可以将修复程序应用于主线，以确保下一个版本不会出现回归。如果下一个版本有一个发布分支打开，则修复程序也需要在该分支上进行。如果发布之间的时间很长，那么修复程序很可能会在已更改的代码之上进行，因此合并起来会更加尴尬。在这种情况下，能够暴露错误的良好测试非常有用。

如果团队正在使用发布分支，则可以在发布分支上完成修复工作，并在完成后发布新版本。本质上，这会将旧的发布分支转换为修复分支。

与发布分支一样，可以在主线上进行修复并将它们挑选到发布分支。但这不太常见，因为修复程序通常是在时间压力很大的情况下完成的。

如果团队进行持续交付，则可以直接从主线发布修复程序。他们可能仍然使用修复分支，但他们将从最新的提交而不是最后发布的提交开始。

我已将新版本标记为 2.2.1，因为如果团队以这种方式工作，则 M4 和 M5 可能不会公开新功能。如果他们这样做了，那么修复程序很可能会被折叠到 2.3 版本中。当然，这说明了在持续交付的情况下，修复程序不需要绕过正常的发布流程。如果团队有一个足够响应的发布流程，那么修复程序可以像往常一样处理 - 这是持续交付理念的显着优势。

持续交付团队适用的一种特殊处理方法是，在修复程序完成之前禁止对主线进行任何提交。这符合这样一种说法，即没有人比修复主线更重要的任务了 - 事实上，这适用于在主线上发现的任何缺陷，即使是那些尚未投入生产的缺陷。（所以我认为这不是真正的特殊处理。）

发布列车

按设定的时间间隔发布，就像火车按定期时刻表发车一样。开发人员在完成其功能后选择要乘坐的列车。

使用发布列车的团队将设置常规的发布节奏，例如每两周或每六个月一次。日期设定为团队何时为每次发布剪切发布分支，遵循火车时刻表的隐喻。人们决定他们希望某个功能赶上哪趟列车，并针对该列车安排他们的工作，在列车装载时将他们的提交放到适当的分支上。一旦列车出发，该分支就是一个发布分支，并且只接受修复。

使用每月列车的团队将根据 2 月份的发布为 3 月份开始一个分支。他们将在整个月内添加新功能。在设定的日期，也许是本月的第三个星期三，火车出发 - 冻结该分支的功能。他们为 4 月份的列车开辟了一个新的分支，并为其添加了新的功能。与此同时，一些开发人员正在稳定 3 月份的列车，并在准备就绪后将其发布到生产环境中。应用于 3 月份列车的任何修复程序都会被挑选到 4 月份的列车中。

发布列车通常与功能分支一起使用。当 Scarlett 感觉到她何时完成她的功能时，她将决定乘坐哪趟列车。如果她认为她可以在 3 月份发布之前完成，她将整合到 3 月份的列车中，但如果没有，她将等待下一趟列车并在那里整合。

一些团队在列车出发（即硬冻结）前几天使用软冻结。一旦发布列车处于软冻结状态，开发人员就不应将工作推送到该列车上，除非他们确信其功能稳定且可以发布。任何在软冻结后添加的、表现出错误的功能都将被还原（从列车上推下），而不是在列车上修复。

如今，当人们听到“发布列车”时，他们通常会听到 SAFe 中的敏捷发布列车概念。SAFe 的敏捷发布列车是一种团队组织结构，指的是共享一个共同发布列车时间表的大型团队。虽然它使用了发布列车模式，但它与我在这里描述的不同。

变体：加载未来的列车

功能列车的基本示例是在前一列车出发时，有一列新列车到达站台以接收功能。但另一种方法是让多列列车同时接受功能。如果 Scarlett 认为她的功能无法在 3 月份的列车上完成，她仍然可以将她大部分完成的功能推送到 4 月份的列车上，并在 4 月份的列车出发之前推送更多提交以完成它。

我们会定期从 3 月份的列车拉取到 4 月份的列车中。一些团队更喜欢只在 3 月份的列车出发时才这样做，因此他们只需要进行一次合并，但我们这些知道小型合并更容易的人更喜欢尽快拉取 3 月份的每次提交。

加载未来的列车允许正在开发 4 月份功能的开发人员进行协作，而不会干扰 3 月份列车上的工作。它的缺点是，如果 4 月份的人员进行了与 3 月份工作冲突的更改，3 月份的人员就不会收到反馈，从而使未来的合并更加复杂。

与从主线进行常规发布相比

发布列车的主要优势之一是定期向生产环境发布。但是，为新开发设置多个分支会增加复杂性。如果我们的目标是定期发布，我们也可以使用主线来实现这一点。确定发布计划，然后根据该计划从主线的尖端剪切一个发布分支。

如果有可发布的主线，则不需要发布分支。使用这样的定期发布，开发人员仍然可以选择通过在定期发布日期之前不推送到主线来将几乎完成的功能保留到下一个版本。使用持续集成，如果人们希望某个功能等待下一个计划的发布，他们始终可以延迟放置关键石或保持功能标志关闭。

可发布的主线

保持主线足够健康，以便始终可以直接将主线的头部投入生产

在本节开始时，我评论说，如果您使主线成为健康分支，并且您将健康检查设置得足够高，那么您可以直接从主线发布，并在需要时使用标签记录发布。

我花了大量时间来描述作为这种简单机制的替代方案的模式，所以我认为现在是时候强调这一点了，因为如果一个团队能够做到这一点，这是一个很好的选择。

仅仅因为每次提交到主线都是可发布的，并不意味着它应该被发布。这是持续交付和持续部署之间的微妙区别。使用持续部署的团队确实会发布每个被主线接受的更改，但是使用持续交付，虽然每个更改都是可发布的，但是否发布是一个业务决策。（因此，持续部署是持续交付的一个子集。）我们可以将持续交付视为让我们可以选择在任何时候发布，而我们行使该选项的决定取决于更广泛的问题。

实验分支

将代码库上的实验性工作收集在一起，这些工作预计不会直接合并到产品中。

实验分支是开发人员想要尝试一些想法的地方，但不要期望他们的更改会被简单地集成回主线。我可能会发现一个新的库，我认为它可以很好地替代我们已经在使用的库。为了帮助决定是否切换，我启动了一个分支，并尝试使用它编写或重写系统的相关部分。练习的目的不是向代码库贡献代码，而是了解新工具在我特定上下文中的适用性。我可以自己做这件事，也可以和一些同事一起做。

类似地，我有一个新功能要实现，并且可以看到几种方法来实现它。我花几天时间研究每种方案，以帮助我决定采用哪一种。

这里的关键是，期望实验分支上的代码将被放弃，并且不会合并到主线中。这并不是绝对的——如果我碰巧喜欢结果并且代码可以很容易地集成，那么我不会忽视这个机会——但我并不*期望*会是这样。我可能会放松一些通常的习惯，减少测试，一些随意的代码重复，而不是试图干净地重构它。我希望，如果我喜欢这个实验，我会从头开始将这个想法应用到生产代码中，使用实验分支作为提醒和指南，但不使用任何提交。

一旦我完成了实验分支的工作，在 git 中，我通常会添加一个标签并删除该分支。该标签保留了代码行，以防我以后想重新检查它——我使用了一个约定，例如以“exp”开头标记名称，以使其性质清晰。

未来分支

用于处理过于具有侵入性而无法使用其他方法处理的更改的单个分支。

这是一种罕见的模式，但在人们使用持续集成时偶尔会出现。有时，团队需要对代码库进行非常具有侵入性的更改，而用于集成正在进行的工作的常用技术并不适用。在这种情况下，团队会做一些看起来很像功能分支的事情，他们会切出一个未来分支，并且只从主线拉取，直到最后才进行主线集成。

未来分支和功能分支之间的最大区别在于，只有一个未来分支。因此，在未来分支上工作的人永远不会偏离主线太远，并且没有其他分支需要处理。

可能有多个开发人员在未来分支上工作，在这种情况下，他们使用未来分支进行持续集成。在进行集成时，他们在集成更改之前，首先从主线拉入未来分支。这将减慢集成过程，但这是使用未来分支的代价。

协作分支

为开发人员创建的一个分支，用于与团队的其他成员共享工作，而无需正式集成。

当团队使用主线时，大多数协作都是通过主线进行的。只有当主线集成发生时，团队的其他成员才会看到开发人员在做什么。

有时，开发人员希望在集成之前共享他们的工作。打开一个分支进行协作允许他们临时进行此操作。该分支可以推送到团队的中央存储库，协作者可以直接从他们的个人存储库中拉取和推送，或者可以建立一个短期存储库来处理协作工作。

协作分支通常是临时的，一旦工作集成到主线中就会关闭。

团队集成分支

允许子团队在与主线集成之前相互集成。

较大的项目可能有多个团队在单个逻辑代码库上操作。团队集成分支允许团队成员相互集成，而无需使用主线与项目的所有成员集成。

实际上，团队将团队集成分支视为团队内部的主线，并像使用整个项目主线一样与之集成。除了这些集成之外，团队还进行单独的工作以与项目主线集成。