根据政策规定，我在这个特定项目中必须使用CVS，因此即使我真的想切换到其他东西（如Git），我也不能。
所以，我的真正问题是这样的：我们有一个约定，每次发布时都会在CVS中创建一个新的分支（我们还会打标签，但这不是重点）。我们称这些为版本分支，它们允许我们轻松地检出特定版本并对其进行热修复更改-这是我们的小版本发布。
但现在我有一些规模较大、风险较高的更改即将到来，如果我在Git中工作，我会眨眼间创建一个功能分支。然而，在CVS中工作时，我尝试在另一个项目中创建功能分支，结果发现事情很快变得混乱。我最终拥有了很多分支，并且我失去了追踪哪些分支已同步，哪些需要合并以及哪些不再使用。
那么，接近问号，CVS是否可以使用功能分支？它们是否太麻烦而不值得使用，或者最终我会因不使用它们而感到遗憾？我应该咬紧牙关，从头开始编码，但弯曲我的编码过程，以最不显眼的方式引入更改吗？
有一个关于分支策略的优秀讨论，称为流线型分支，可能会有所帮助 - 它描述了使用特性分支的优缺点。
它还涵盖了代码所有权和您可能希望实施的政策的选项。
需要考虑的一件事是，当你完成了功能分支的合并后，实际上要关闭它。在这种情况下，关闭只是指放弃该分支，而不是真正的删除。
一旦工作被合并，就没有必要让该分支“存在”了。
为了快速识别哪些分支是功能分支，建议使用命名约定如“FEAT_MY_FEATURE”或“FEAT_20080926”（开始日期？）。这将使浏览存储库结构时轻松忽略所有这些功能分支。
我曾在一个环境中工作了几年，这种做法很常见，但真的很痛苦。确保合并是项目计划的一部分，因为它们将消耗大量时间并成为延迟的来源。
记录分支并为它们分配特定的责任有所帮助。
我们不得不创建一个工具来帮助我们逐步合并更改（一次只合并一个更改，而不是合并分支的顶端），因为如果两个分支分歧，CVS 的行为不好。
经常同步（至少每周一次）。
我认为回顾这个问题的最佳方法是确保分歧保持最小，并使用 Scrum 将风险开发拆分为不同的里程碑。
我还鼓励您阅读 SCM Patterns。这本书包含了许多好的建议。
