您什么时候应该分支？

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

分支有多种用途。最常见的用途之一是分离曾经具有通用代码库的项目。这对于在不影响主干的情况下试验代码非常有用。

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

• Feature Branch：如果某个特定功能的破坏性足以使您不希望整个开发团队在早期阶段受到影响，则可以创建一个分支来执行此工作。

• Fixes分支：在主干上继续进行开发时，可以创建一个fixes分支，以将修补程序保存到该软件的最新发行版。

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

• Ned Batchelder-Subversion分支快速入门

一般而言，分支（VCS-版本控制系统功能）的主要目的是实现代码隔离。

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

但是该模型很快显示出其局限性：

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

因此，这就是您的答案：
应该在无法进行任何活动并将其记录在一个分支中的两次记录上时分支。
（无需保留极其复杂的历史记录）。

即使您是唯一处理源代码的分支，分支也是很有用的，即使您很多。
但是，您不应该“每个开发人员一个分支”：
“隔离”目的是为了隔离开发工作（这项任务可以像“让我们开发软件的下一版本”一样笼统，也可以像“让我们修复”一样具体。错误23”），
而不是隔离“资源”。

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

分支不是标签（SVN是一个修订系统，它试图提出版本控制功能，例如使用便宜的文件副本在目录中进行分支和标记：这并不意味着标签是分支）

定义分支还意味着定义合并工作流程：完成分支后，您需要知道在哪里合并分支。
为此，Practical Perforce（Laura WINGERD-O'Reilly）的第7章是很好的介绍（与VCS无关），可以将不同种类的分支之间的工作流合并：“” 软件如何演变 “（pdf）

它定义了术语代码行（通过特定点的标签或通过重要的合并返回分支来记录代码的重要演化步骤的分支）

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

• 活跃的开发流：连续进行各种开发时的持久代码行
• 任务分支：适用于特定任务的短暂分支（错误修复是经典的分支，但是您也可以为已知复杂的合并工作定义一个分支：您可以在该任务分支中进行合并，提交和测试不会为当前的主要开发分支引入问题）
• 登台分支：用于准备发布，其中包含一些生产前特定的数据或配置文件。
• 专用分支机构，临时分支机构和稀疏分支机构：对于非常小的任务，只需要能够进行一些正在进行的工作，而无需等待正式完成或测试复查。
  这样可以“提早提交，经常提交”。

_{有关VCS的其他有趣概念：基础概念
（最初是关于ClearCase的，但也适用于任何VCS）}

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

分支您要执行的每个任务，无论这是一项新功能，错误修正，测试还是其他任务。这称为主题分支，它改变了您使用SCM的方式。

你得到：

• 更好的隔离
• 更好的可跟踪性->您将任务与分支而不是单个变更集相关联，这使您可以随意提交任意多次，并且不会像“每个任务一次签入”那样施加限制。
• 任务是独立的（通常从稳定的基线开始，因此您只关注代码，而不关注修复人员的错误），并且可以选择是在某个时候还是以后集成它们，但是它们始终处于版本控制
• 在点击主线之前，您可以轻松地检查代码（从版本控制中，而不是预先提交废话）

可以做到的工具：

• 吉特
• 水银
• 塑料单片机

无法做到的工具：

• SVN
• CVS
• VSS
• TFS
• Perforce

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

其他SCM，例如subversion和CVS，则具有“更重”的分支范例。这意味着，只将分支视为适用于大于二十多行的补丁。在那里，分支通常用于跟踪整个开发轨道，例如以前或将来的产品版本。

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

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

在较新的分布式版本（如git和mercurial）中，您一直在创建分支并始终合并。我经常会在一个单独的分支上工作一段时间，只是因为有人破坏了主线的构建，或者是因为网络中断了，然后在固定修复之后将更改合并回去，而且这样做很容易，甚至都不会令人讨厌。

最能帮助我了解分布式系统中内容的文档（简短易懂）是：谅解Mercurial。

在具有中央存储库的较旧系统（例如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中的标签，尽管本质上只是一个“正常分支”）。它们提供了静态的快照，例如发布。即使可以进行处理，它们也保持不变。

也可能需要分支：

每当您有喜欢的时候。

如果您使用集中式SCM，您可能不会很频繁，因为分支机构是官方存储库的一部分，并且这实际上并不需要太多的实验，更不用说合并确实很麻烦。

OTOH，在分布式SCM中，分支和结帐之间没有技术上的区别，并且合并要容易得多。您会感觉更经常分支。

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

例如，我们通常在行李箱上工作。在发行期间，有些人将需要进行当前版本中我们不希望的更改（可能在发行前，通常在发行后）。这是我们分支的时候，将发行版放到自己的分支上，并继续在主干上开发下一个发行版。

抛开所有技术知识.....

当您知道它更易于合并时分支！

请记住，合并总是会受到项目中工作方式的影响。

一旦实现这一目标，所有其他第三纪将发挥作用。