什么时候应该分支？

Posted 2021-05-03

使用SCM系统时，何时应该分支？

答案

分支有几种用途。最常见的用途之一是分离曾经具有公共代码库的项目。这对于试验代码非常有用，而不会影响主干。

通常，您会看到两种分支类型：

• 功能分支：如果某个特定功能具有破坏性，您不希望整个开发团队在其早期阶段受到影响，您可以创建一个分支来执行此工作。
• 修复分支：在主干上继续开发时，可以创建修复分支以将修复程序保存到最新发布的软件版本中。

您可能有兴趣查看以下文章，该文章解释了分支的原理以及何时使用它们：

• Ned Batchelder - Subversion branching quick start

另一答案

无论什么时候你都喜欢它。

如果您使用集中式SCM，您可能不会经常使用，因为分支机构是官方存储库的一部分，并且实际上并没有真正邀请太多实验，更不用说合并真的很糟糕。

OTOH，分布式SCM中的分支和结账之间没有技术差异，合并更容易。你会觉得分支更频繁。

另一答案

当您需要根据当前分支进行更改时，不会发往该分支的下一个版本（而不是之前）。

例如，我们通常在trunk上工作。在发布之前，有人需要在当前版本中进行我们不想要的更改（可能在发布之前，通常在发布之后）。这是我们分支时，将发布版本放在自己的分支上，并继续开发下一版本的trunk。

另一答案

抛开所有技术细节......

分支当你知道它更容易合并回来！

请记住，合并将始终与项目中的工作方式有关。

一旦实现了这一切，所有其他的三级问题都将发挥作用。

另一答案

总的来说，分支的主要目的（VCS - 版本控制系统 - 功能）是实现代码隔离。

您至少有一个分支，足以进行顺序开发，并用于在同一个唯一分支上记录（提交）的许多任务。

但该模型迅速显示其限制：

当您进行开发工作（重构，演变，错误修复，......）并且您意识到您无法在与当前开发分支相同的分支中安全地进行这些更改（因为您将破坏API，或者引入会破坏的代码）一切），然后你需要另一个分支。 （为了隔离旧代码的新代码，即使稍后将合并这两个代码集）

那就是你的回答： 只要你不能在一个分支中追求并记录两个开发工作，就应该进行分支。 （没有一个非常复杂的历史来维护）。

---

即使你是唯一一个处理源代码的人，如果你很多，分支也很有用。 但你不应该为每个开发人员制作一个分支： “隔离”的目的是为了隔离开发工作（一个可以像“让我们开发我们软件的下一个版本”那样一般的任务，或者像“让我们修复bug 23”那样具体）， 不要孤立“资源”。

（一个名为“VonC”的分支对另一个开发者来说没有任何意义：如果“VonC”离开项目怎么办？你应该怎么做呢？ 例如，可以在错误跟踪系统的上下文中解释一个名为“bugfix_212”的分支，并且任何开发人员都可以使用它，至少有一些关于他应该用它做什么的想法）

分支不是标签（SVN是Revision System，tries to propose versioning features喜欢分支和标记通过廉价文件副本的目录：这并不意味着标签是分支）

要定义分支意味着还要定义merge workflow：您需要知道在完成分支时合并分支的位置。 为此，Practical Perforce的第7章（La​​ura WINGERD - O'Reilly）是一个很好的介绍（VCS不可知），用于合并不同类型的分支之间的工作流程：“”How Software Evolves“（pdf）

它定义术语代码行（分支记录代码的重要演变步骤，通过某些点的标记，或通过重要的合并回到分支）

它介绍了主线模型（记录发布的中心代码行），并描述了分支的各种用途：

• 活跃的开发流：当顺序的各种开发发生时，持久的代码行
• 任务分支：用于更具体任务的短期分支（错误修复是一个经典的分支，但您也可以为合并工作定义一个分支，您知道要完成复杂：您可以在该任务分支中合并，提交和测试没有为主要的当前开发分支引入问题）
• 暂存分支：用于准备发布，具有一些预生产特定数据或配置文件。
• 私有分支，临时分支和稀疏分支：对于非常小的任务，只是为了能够在不等待正式完成或测试审查的情况下提交正在进行的工作。 这允许“提前提交，经常提交”。

---

围绕VCS的其他有趣概念：Basics concepts （最初关于ClearCase，但对任何VCS也有效）

另一答案

所有21世纪的SCM都在告诉你：

分支你要处理的每一项任务，无论这是一个新功能，一个错误修正，一个测试，等等。这称为主题分支，它会改变您使用SCM的方式。

你得到：

• 更好的隔离
• 更好的可追溯性 - >您将任务与分支相关联，而不是单独的变更集，这使您可以随意提交任意次数，并且不会施加“每个任务一次检查”等限制。
• 任务是独立的（通常从稳定的基线开始，所以你只专注于你的代码，而不是修复你的人的错误），你可以选择是否要在某个时间或之后集成它们，但它们总是在版本控制
• 您可以在点击主线之前轻松查看代码（从版本控制，而不是预先提交废话）

可以做到的工具：

• Git
• Mercurial
• Plastic SCM

无法做到的工具：

• SVN
• CVS
• VSS
• TFS
• Perforce公司

另一答案

它还取决于您使用的SCM工具。现代SCM（git，mercurial等）使得在需要时创建和销毁分支变得越来越容易。例如，这允许您为每个正在处理的错误创建一个分支。将结果合并到主干后，您将丢弃分支。

其他SCM，例如颠覆和CVS，具有更“重”的分支范例。这意味着，分支被认为仅适用于大于二十几行补丁的东西。在那里，分支通常用于跟踪整个开发轨道，如先前或未来的产品版本。

另一答案

当您需要对代码库进行重大和/或实验性更改时，特别是如果您要提交中间更改，而不影响主干。

另一答案

这取决于您使用的SCM类型。

在较新的分布式版本（如git和mercurial）中，您始终在创建分支并重新进行重新分类。我经常在一个单独的分支上工作一段时间只是因为某人破坏了主线上的构建，或者是因为网络崩溃了，然后在修复后合并更改，这很容易做到它甚至不讨厌。

最能帮助我理解分布式系统中的内容的文档（简短且可读）是：UnderstandingMercurial。

在具有中央存储库的旧系统中（如CVS，SVN和ClearCase），这是一个需要在团队级别决定的更严重的问题，答案应该更像是“在允许的同时保持旧版本发展继续在主线'，或'作为主要实验的一部分'。

我认为，分布式模型要好得多，并且缺乏很好的图形工具才能成为主导范例。然而，它并没有被广泛理解，并且概念是不同的，因此它可能会让新用户感到困惑。

另一答案

我发现Perforce的Laura Wingerd和Christopher Seiwald的建议非常简洁实用：

* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.

请参阅http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf，了解每种方法和其他最佳实践的详细说明。

另一答案

分支有多种用途：

1. 功能/错误分支。动态和活动分支在功能/错误修复完成后移回主干。
2. 静态分支（Subversion中的标记，但实质上只是一个'普通分支'）。它们提供了一个静态快照，例如发布。即使他们可以继续工作，他们仍然没有受到影响。

另一答案

也可能出现分支的需要：

当您想要为特定客户提供修补程序（比较重要）时，您不确定该修补程序是否将成为未来版本的一部分