分支还是不分支，这是一个有趣的问题。本章到目前为止已经深入探讨了分支和合并，这些主题历来是 Subversion 用户困惑的主要来源。分支和分支管理中涉及的例行操作本身有时并不容易，一些用户在决定是否需要分支时会感到困惑。正如您所了解的，Subversion 可以处理常见的分支和分支管理场景。因此，决定是否要分支项目的历史记录很少是一个技术问题。相反，决策的社会影响通常更重要。让我们来考察一下在软件项目中使用分支的一些好处和成本。

在分支上工作最明显的好处是隔离。对分支所做的更改不会影响项目中的其他开发线路；对其他开发线路所做的更改不会影响分支。这样，分支可以成为实验新功能、复杂错误修复、主要代码重写等的好地方。无论莎莉在她的分支上破坏了多少东西，哈利和团队的其他成员都可以在分支之外继续不受干扰地工作。

分支还提供了一种很好的方法来将相关的更改组织成易于识别的集合。例如，包含特定错误的完整解决方案的更改可能是一系列非连续的修订号。您可以在人类语言中将它们描述为 “修订版本 1534、1543、1587 和 1588”。您可能需要在跟踪错误的工单跟踪工具中手动（或以其他方式）复制这些数字。在将错误修复移植到其他产品版本时，您需要确保移植所有这些修订版本。但是，如果这些更改是在唯一的分支上进行的，您会发现自己只通过名称在对话中、在工单跟踪评论中以及移植更改时引用该分支。

但是，分支的不幸缺点是，使它们如此有用的隔离性 可以 与项目团队的协作需求相冲突。根据项目同伴的工作习惯，对分支所做的更改可能无法获得对主开发线路所做的更改进行的建设性审查、批评和测试。分支的隔离可能会鼓励用户放弃某些版本控制 “最佳实践”，导致版本历史难以 事后 审查。在长期分支上工作的开发人员有时需要更加努力地确保其代码库的隔离副本的演化方向与同伴引导主代码线路的方向一致。现在，对于旨在探索代码库未来的真正探索性分支来说，这些缺点可能不是什么大问题，而这些分支没有将结果重新整合到主开发线路中的预期——仅仅是政策不需要成为破坏愿景的杀手！但事实仍然是，项目通常会受益于版本控制的有序方法，在这种方法中，代码和代码更改会得到多位团队成员的审查和理解。

这并不是说分支没有技术上的弊端。在我们 “元化” 一点之前，请原谅我们。如果您仔细想想，每次签出 Subversion 工作副本时，您都在创建项目的某种分支。这是一种特殊类型的分支。它只存在于您的客户端机器上；而不是在存储库中。您使用 svn update 将此分支与存储库中所做的更改同步，这几乎就像是对 svn merge 命令的特殊情况的简化形式。 ^[47] 每次运行 svn commit 时，您都会有效地重新整合分支。因此，从这个特殊意义上来说，Subversion 用户一直都在处理分支和合并。鉴于更新和合并之间的相似性，因此并不奇怪，Subversion 似乎存在最大缺点的领域——即处理文件和目录重命名以及处理一般的树冲突——对于 svn update 和 svn merge 操作来说都是有问题的。不幸的是，svn merge 的问题更大，恰恰是因为 svn update 是一种特殊情况的简化通用合并操作，而真正的 Subversion 合并既不是特殊情况，也不是简化。出于这个原因，合并比更新执行得慢得多，需要显式跟踪（通过我们在本章中讨论过的 svn:mergeinfo 属性）和历史记录压缩运算，并且通常会为出现问题提供更多机会。

分支还是不分支？最终，这取决于您的团队需要什么才能找到协作和隔离的最佳平衡。