应用错误收集

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

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

您至少拥有一个分支，这对于顺序开发来说足够了，并且用于在同一个唯一分支上记录（提交）的许多任务。

但该模型很快显示出其极限：

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

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

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

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

分支不是标记（SVN是Revision System，tries to propose versioning feature就像使用廉价文件副本分支和标记目录一样：这并不意味着标记是分支）

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

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

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

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

_{围绕VCS的其他有趣概念：Basics concepts

（最初关于ClearCase，但对任何VCS也有效）}

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

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

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

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

Ned Batchelder - Subversion branching quick start

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

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

你得到：

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

可以做到的工具：

无法做到的工具：

SVN
CVS
VSS
TFS
Perforce的

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

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

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

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

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

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

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

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

我从Laura Wingerd＆amp; amp; Perforce的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，了解每个问题的详细说明以及其他最佳做法。

分支有多种用途：

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

也可能出现分支的需要：

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

每当你想要的时候。

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

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

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

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

将所有技术细节放在一边.....

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

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

一旦达到这一目标，其他所有高等教育问题都会发挥作用。

什么时候应该分支？

12 个答案: