我有义务在这个特定项目中使用 CVS，所以即使我真的想切换到其他东西，比如 Git，我也不能。
所以，我真正的问题是这样的：我们有一个约定，每次发布时我们都会在 CVS 中创建一个新分支（我们也标记，但这不是重点）。我们称这些版本分支，它们使我们能够轻松地检查特定版本并对其进行热修复更改 - 这就是我们的次要版本。
但是现在我有一些大的、充满风险的变化即将到来，如果我在 Git 中工作，我会在眨眼之间创建一个功能分支。然而，在 CVS 中工作时，我尝试在另一个项目中创建功能分支，但很快发现事情变得一团糟。我最终得到了很多分支，但我忘记了哪些分支已同步，哪些需要合并，哪些不再使用。
那么，接近问号，在 CVS 中使用特征分支是否可行？它们是不是太麻烦而不值得，还是我最终会因为不使用它们而感到抱歉？我是否应该硬着头皮开始在 HEAD 中编码，但要弯曲我的编码过程，以尽可能不引人注意的方式引入更改？
如果您是唯一一个在功能分支上进行开发的人，您可以简单地将 Git 作为您的“沙盒开发”系统，然后在完成更改后，将它们合并到您的 CVS 存储库中。
您仍然可以获得中间工作产品的源代码控制的好处。
对称为流线的分支策略进行了精彩的讨论，这可能会有所帮助 - 它描述了使用特征分支的优点和缺点。
它还涵盖了您可能希望实施的代码行所有权和策略选项
需要考虑的一件事是，在完成功能分支后，在将其与主干合并后实际关闭它。在这种情况下，关闭只是意味着放弃分支，而不是真正的删除。
一旦工作被合并，分支就真的没有必要“存在”了。
为了快速识别哪些分支是功能分支，我建议使用命名约定泄漏“FEAT_MY_FEATURE”或“FEAT_20080926”（开始日期？）。这将使在浏览存储库结构时忽略所有这些功能分支变得容易。
我已经在这样的环境中工作了几年，这是一种常见的做法，而且真的很痛苦。确保合并是您项目计划的一部分，因为它们会消耗大量时间并且是延迟的来源。
记录分支并为它们分配特定职责会有所帮助。
我们必须创建一个工具来帮助我们逐步合并更改（一次一个更改，而不是合并分支的尖端），因为如果两个分支出现分歧，CVS 的表现就不好。
经常同步（至少每周一次）。
我认为回想起来解决这个问题的最佳方法是确保差异保持最小，并通过使用 Scrum 将风险开发划分为不同的里程碑。
我还鼓励您阅读SCM 模式。这本书包含了很多很好的建议。