在该特定项目中使用CVS是我的职责，因此即使我真的要切换到其他工具(如Git)，我也不能。

因此，我真正的问题是这样的：我们有一个约定，即每次发布版本时，我们都会在CVS中创建一个新分支(我们也进行了标记，但这并不重要)。我们称这些版本分支为例，它们使我们能够轻松地检出特定版本并对其进行热修复，这就是我们的次要发行版。

但是现在我要进行一些大的，充满风险的更改，如果我在Git中工作，我将在眨眼之间创建一个功能分支。但是，在CVS中工作时，我尝试在另一个项目中创建功能分支，结果发现事情很快就变得混乱了。我最终得到了很多分支，而我失去了对哪些分支已同步，哪些需要合并以及哪些不再使用的跟踪。

那么，随着距离问点越来越近，在CVS中使用功能分支是否可行？它们太麻烦了，不值得吗？还是我最终会因不使用它们而感到抱歉？我是否应该硬着头皮开始在HEAD中进行编码，但会弯腰编码过程，以尽可能不引人注目的方式介绍所做的更改？

解决方案

要考虑的一件事是，一旦完成将功能分支与主干合并后，实际上就将其关闭。在这种情况下，关闭只是意味着放弃分支，而不是真正的删除。

合并工作后，实际上就不需要分支"存在"了。

为了快速识别哪些分支是要素分支，我建议使用命名约定泄漏" FEAT_MY_FEATURE"或者" FEAT_20080926"(开始日期？)。在浏览存储库结构时，这将很容易忽略所有这些功能分支。

如果我们是功能分支上唯一的开发人员，则可以简单地将Git用作"沙盒开发"系统，然后在完成更改后将其合并到CVS存储库中。

我们仍然可以在中间工作产品中获得源代码控制的好处。

关于称为流线的分支策略，进行了精彩的讨论，这可能有助于描述使用特征分支的优缺点。

它还涵盖了我们可能想要实施的代码行所有权和策略的选项

我已经在这种环境下工作了几年，这确实很痛苦。确保合并是项目计划的一部分，因为合并将消耗大量时间并且是延迟的来源。

记录分支机构并为其分配具体职责有所帮助。

我们必须创建一个工具来帮助我们渐进地合并更改(一次更改一次，而不是合并分支的尖端)，因为如果两个分支分开，CVS的表现将不佳。

经常同步(至少每周一次)。

我认为，回顾此问题的最佳方法是确保差异最小化，例如通过使用Scrum将风险发展划分为不同的里程碑。

我也鼓励我们阅读SCM模式。这本书包含很多好的建议。