解释这些最佳实践的需求的最佳方法是通过一个真实的项目场景示例，展示这些最佳实践如何融入 “大局”。 此外，许多读者告诉我，分支与合并和 变更传播章节需要示例才能更好地解释。 倾听读者的意见是好事，因此我整理了一个特定的项目场景，并创建了一系列事件，以展示如果遵循最佳实践，将如何帮助操作更顺畅。
考虑一个软件项目，其中 1.0 版本刚刚投入生产，大家都庆祝完毕。 下一步是开始开发后续版本的新功能。 此外，系统的用户已经开始全职使用它，各种级别的 bug 报告也开始涌入。
在开始进行新的增强功能或 bug 修复之前，应遵循 分支与合并的最佳实践。 一些重要的实践是 为每个版本打标签 和 在每个版本发布后创建一个分支。 这些实践将有效地建立两个 “开发环境”，一个用于常规增强功能，另一个用于上一个版本的 bug 修复和小幅增强。
假设该版本被标记为
release_1_0
然后创建了分支，分支名称为
release_1_0_patches
现在，我们准备开始工作了。 让我们检查一下 bug 修复和增强功能跟踪。 假设有三个 bug，其中两个是高优先级的，应该立即修复（可能在一周内），第三个可以在一段时间后交付（比如 4 周后）。 在这个时间表的中间，有一个常规版本计划在三周后发布。 考虑到我们接下来一个月很忙，让我们看看如何使用最佳实践来缓解接下来的工作压力。
下个月各个版本的发布时间表如下所示。
Fix Enhancement Fix
Today Release 1 Release Release 2
|_______|______________|_________|
Time -->
|
我们有两个团队，一个团队在 bug 修复分支上工作，另一个团队在主干上开发下一个版本的功能。 这些团队必须确保他们在沙箱中使用正确的版本开始工作。
bug 修复团队将使用命令行检出
cvs checkout -R -r release_1_0_patches {项目名称}
正在开发下一个版本的团队将使用命令行
cvs checkout -R {项目名称}
一旦 bug 修复团队完成两个最高优先级的 bug，他们将更新、验证构建成功，并使用命令行将更改提交到 bug 修复分支
cvs update -R -r release_1_0_patches {模块名称}团队应在此处执行构建，以验证更新是否没有破坏分支上的任何代码。 一旦构建成功，应该将分支提交回代码仓库。
cvs commit -R -r release_1_0_patches {模块名称}尽早构建，频繁构建：每天，每个开发人员都会将代码签入 CVS，为了确保代码的健全性，将在 bug 修复分支上执行每日构建，方法是从干净环境中的 CVS 检出并完全重建。 这些每日构建可以使用以下命名约定在 CVS 中标记
build_1_1_yyyymmdd : 用于分支
build_2_0_yyyymmdd : 用于主干
遵循构建-测试-修复的常规流程，使版本准备好交付。 标签将帮助开发人员在必要时检出最新构建的工作副本。
当源代码发布到外部世界时，必须遵循两个实践。
为每个版本打标签：这确保 bug 修复版本被正确标记，因此可以在以后必要时追溯。
在发布后将分支与主干合并：这确保 bug 修复被合并回主干，确保所有未来的版本都是真正的累积交付。