CVS中的功能分支？

Question

我有责任在这个特定的项目中使用CVS的政策，所以即使我真的要切换到别的东西，比如Git，我也不能。

所以，我真正的问题是这样的：我们有一个约定，我们每次发布时都会在CVS中创建一个新的分支（我们也标记，但这不是重点）。我们称这些版本为分支，它们允许我们轻松检出特定版本并对其进行热修改 - 这就是我们的次要版本。

但现在我有一些大风险，冒险的变化，如果我在Git工作，我会在眨眼之间创建一个功能分支。然而，在CVS工作，我尝试在另一个项目中创建功能分支，发现事情很快变得混乱。我最终得到了很多分支，我忘记了哪些分支被同步，需要合并，哪些分支不再使用。

因此，更接近问号，在CVS中使用特征分支是否可行？他们是不是很值得，或者我最终会因为不使用它们而感到抱歉？我应该咬紧牙关，只是开始在HEAD中编码，但是弯曲我的编码过程以尽可能最不引人注目的方式引入变化？

Answer 1

如果您是唯一一个在功能分支上开发的人，您可以简单地使用Git作为“沙箱开发”系统，然后在完成更改后将它们合并到CVS存储库中。

您仍然可以获得中间工作产品的源代码管理权益。

Answer 2

对于名为streamed lines的分支策略进行了很好的讨论，这可能有所帮助 - 它描述了使用特征分支的优缺点。

它还涵盖了您可能希望实施的代码行所有权和政策的选项

Answer 3

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

一旦工作合并，分支就不需要“存在”。

为了快速识别哪些分支是特征分支，我建议命名约定泄漏“FEAT_MY_FEATURE”或“FEAT_20080926”（开始日期？）。这样可以在浏览存储库结构时轻松忽略所有这些功能分支。

Answer 4

我在一个环境中工作了好几年，这是常见的做法，真的很痛苦。确保合并是项目计划的一部分，因为它们将耗费大量时间并且是延迟的来源。

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

我们必须创建一个工具来帮助我们逐步合并更改（一次更改一次，而不是合并分支的尖端），因为如果两个分支发散，CVS的表现不佳。

经常同步（至少每周一次）。

我认为回顾这一问题的最佳方法是确保分歧仍然微乎其微，并通过使用Scrum来分解不同里程碑的风险发展。

我也鼓励您阅读SCM Patterns。这本书包含很多好的建议。