源控制概念 - 每个功能的分支，每次检入的标记

Question

我正在阅读有关“branch per feature”和this one too的帖子，并发现自己想知道有多少人使用这个概念？我将全部用于持续集成和标记每次签入。在迭代结束时，我创建一个特殊的标记集来标识sprint结果。我从未需要为每个功能开发创建一个特殊的分支。

问题：是否有人为其代码库中的每个功能的开发分支代码？如果是这样，为什么这样做，你从这个过程中看到了什么好处？团队中面向非流程的开发人员会采用这种方法吗？

Answer 1

我没有听说过这样的事情。似乎过度使用分支给我。我想这取决于我们所说的“功能”这个词。这是一个用例吗？用户故事？整个迭代？

分支意味着并行发展。如果你不是并行开发，为什么要分支？

我们的主持人Jeff Atwood提供了一些很好的SCM参考资料：

1. Eric Sink
2. Branching and Merging Primer

当然，SVN红豆书：

http://svnbook.red-bean.com/

我也喜欢"Pragmatic Version Control"关于分支和标记的内容。

Answer 2

对我来说，按功能分支只有在你有一个足够大的项目时才有意义，你可以聪明地说出“X功能团队”作为一个独立单元。

此外，还有一定的尺寸标准（公认模糊）。如果你有10个开发人员，就我而言，你只有1个功能团队 - 如果他们中的两个总是“小部件对话框人”或“数据库人员”并不重要。如果某人正在进行主要重构，对API进行重大更改，改变预期行为以使许多BVT失败等，您可能需要＆gt; 1开发分支。但这不是功能分支。

如果您有100名开发人员，则可能需要功能分支。这取决于您的功能的紧密耦合程度以及SCM流程的规范程度，特别是在构建质量方面。即使您没有功能分支，您也肯定会有某种类型的分支层次结构。

如果您正在使用Windows，图层和特色分支层是天赐之物。如果shell团队由于内核团队引入了一个bug而无法提高效率，那就是一个很大的问题。

当然，还有一个平衡的行为。一些大型组织过度使用功能分支。当功能团队X祝福的代码在团队Y之前开始需要几个月时，合并+集成测试的痛苦将超过您首先尝试获得的代码库稳定性。 （因此短语“你的树从MAIN的深度与你的理智成反比”）并且在每种情况下，版本N的树必须在其释放接近时缩小，最终折叠到仅直接检查到该释放的行李箱的点将是包括在内，每个功能分支都有效地针对N + 1。

Answer 3

我甚至会进一步实施"branch per task"，在问题跟踪系统中为每个问题使用分支（你知道，bugzilla，JIRA等）。

它听起来有点“极端”，但如果您使用支持分支的SCM（如Git，Mercurial或Plastic）（我当然偏向塑料，当然：P），它非常容易理解。

Answer 4

功能分支与Scrum配合良好，偶尔积压项目尚未准备好在sprint结束时发布。你希望避免这种情况，但它必然会不时发生。当它确实发生时，你只需合并完整的积压项目，而不合并那些没有的积压项目。如果需要，未完成的那个可以移动到下一个sprint，或者放回到积压中并稍后工作。在任何情况下，您仍然拥有分支，因此您不必丢弃已经提交的代码。