使用SCM系统时，何时应该分支？
分支有几种用途。最常见的用途之一是分离曾经具有公共代码库的项目。这对于试验代码非常有用，而不会影响主干。
通常，您会看到两种分支类型：
您可能有兴趣查看以下文章，该文章解释了分支的原理以及何时使用它们：
无论什么时候你都喜欢它。
如果您使用集中式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章（Laura WINGERD - O'Reilly）是一个很好的介绍（VCS不可知），用于合并不同类型的分支之间的工作流程：“”How Software Evolves“（pdf）
它定义术语代码行（分支记录代码的重要演变步骤，通过某些点的标记，或通过重要的合并回到分支）
它介绍了主线模型（记录发布的中心代码行），并描述了分支的各种用途：
围绕VCS的其他有趣概念：Basics concepts （最初关于ClearCase，但对任何VCS也有效）
所有21世纪的SCM都在告诉你：
分支你要处理的每一项任务，无论这是一个新功能，一个错误修正，一个测试，等等。这称为主题分支，它会改变您使用SCM的方式。
你得到：
可以做到的工具：
无法做到的工具：
它还取决于您使用的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，了解每种方法和其他最佳实践的详细说明。
分支有多种用途：
也可能出现分支的需要：