6. 分支与合并
CVS 中的分支将项目开发分成独立的并行历史记录。在一个分支上进行的更改不会影响其他分支。分支可以广泛用于维护产品的多个版本，以提供支持和新功能。
合并将分支汇聚回主干。在合并中，CVS 计算分支上自其从主干分叉点到分支顶端（其最新状态）之间所做的更改，然后将这些差异应用到主干顶端的项目。
6.1. 为主干和分支分配所有权
源代码树的主干和各个分支都应该分配一个负责人，负责以下事项。
保留分支或主干的可配置项列表。
负责人将是分支或主干的内容列表的维护者。此列表应包含项目名称和关于该项目的简要描述。此列表至关重要，因为新的工件始终在持续地添加到或从存储库中移除。此列表将能够跟踪各个分支存储库的新增/删除项。
为分支或主干建立工作策略。
负责人将建立检入和检出策略。该策略将定义何时可以检入代码（编码后或审查后等）。谁负责合并同一文件上的更改并解决冲突（作者或最近更改文件的人）。
识别并记录策略偏差
一旦建立的策略往往会有例外情况。负责人将负责识别解决方法并跟踪/记录下来以供将来使用。
负责与主干合并
分支负责人将负责确保分支中的更改可以在合理的时间点成功合并到主干。
6.2. 标记每个发布版本
作为发布过程的一部分，整个代码库必须用一个标识符进行标记，该标识符可以帮助唯一标识发布版本。标签为由一个开发人员的工作副本表示的修订集合提供标签（通常，该工作副本是完全最新的，因此标签名称附加到存储库中的“最新和最好的”修订版本）。
标签的标识符应提供足够的信息，以便在将来任何时间点识别发布版本。一个建议的标签标识符形式如下。
release_{major version #}_{minor version #}
 | 正如一位读者向我指出的那样，这里的一个好做法是首先标记发布版本。使用标签检出整个代码库，然后继续进行构建/部署/测试过程，然后再进行实际发布。这将绝对确保“离开家门”的是经过验证和测试的代码库。 |
6.3. 每次发布后创建一个分支
每次软件发布后，一旦 CVS 存储库被标记，就必须立即创建一个分支。此分支将作为该发布版本的错误修复基线。仅当发布版本首先不是错误修复或补丁发布版本时，才会创建此分支。将来任何时候必须为此发布版本制作的补丁将在该分支上开发。主干将用于持续的产品开发。
通过这种安排，用于持续开发的代码更改将在主干上，并且该分支将为热修复和错误修复发布提供单独的分区。
分支名称的标识符可以是以下形式。
release_{major version #}_{minor version #}_patches
6.4. 仅对分支进行错误修复
这种做法是从之前在主要发布后创建单独分支的做法延伸而来。该分支将作为必须进行的所有错误修复和补丁发布的代码库。因此，有一个单独的存储库“沙箱”，可以在其中开发热修复和补丁，而无需进行主流开发。
这种做法还确保对先前版本进行的错误修复不会神秘地影响主流版本。此外，添加到主流版本的新功能不会意外地渗入补丁发布版本。
6.5. 仅从分支制作补丁发布
由于给定发布版本的所有错误修复都在其对应的分支上完成，因此补丁发布版本是从分支制作的。这确保了对作为补丁发布版本一部分发布的功能集不会产生混淆。
制作补丁发布版本后，必须使用发布版本标记实践对分支进行标记（请参阅标记每个发布版本）。