我正在阅读这篇关于“每个功能分支”和这也是，我发现自己想知道有多少人在使用这个概念？ 我完全支持持续集成并标记每次签入。在迭代结束时，我创建一个特殊的标记集来识别冲刺结果。 我从来不需要为每个功能开发创建一个特殊的分支来进一步发展。
问题：是否有人为代码库中的每个功能的开发分支代码？ 如果是这样，您为什么要这样做？您从这个过程中看到了哪些好处？ 您团队中非面向流程的开发人员是否接受这种方法？
I was reading this post about "branch per feature" and this one too and found myself wondering how many people out there are using this concept? I am all for continuous integration and tagging each check in. And at the end of an iteration I create a special tag set to identify the sprints result. I have never needed to take it further by creating a special branch for each features development.
Question: Does anyone branch their code for the development of each feature in their code base? If so, why do you do that and what are the benefits that you have seen from this process? Do the non-process oriented developers on your team buy off on this approach?
发布评论
评论（4）
我没听说过这样的事。 对我来说似乎过度使用了分支。 我想这取决于我们所说的“功能”一词的含义。 这是一个用例吗？ 用户故事？ 整个迭代？
分支意味着并行开发。 如果你不是并行开发，为什么要分支？
我们的主持人 Jeff Atwood 提供了一些很好的 SCM 参考资料：
当然还有SVN红豆书:
http://svnbook.red-bean.com/
我也喜欢“实用版本控制”必须谈到分支和标记。
I haven't heard of such a thing. Seems like an overuse of branching to me. I guess it depends on what we mean by the word "feature". Is it a use case? A user story? An entire iteration?
Branches imply parallel development. If you aren't developing in parallel, why branch?
Some good SCM references from our host, Jeff Atwood:
And, of course, the SVN red bean book:
http://svnbook.red-bean.com/
I also like what "Pragmatic Version Control" has to say about branching and tagging.
对我来说，只有当您有一个足够大的项目，您可以将“X 功能团队”作为一个独立单元进行明智地讨论时，按功能进行分支才有意义。
此外，还有一定的尺寸标准（诚然是模糊的）。 如果您有 10 名开发人员，那么就我而言，您只有 1 个功能团队 - 如果其中两个始终是“小部件对话框人员”或“数据库人员”，这并不重要。 如果有人正在进行重大重构、对 API 进行重大更改、改变预期行为从而导致许多 BVT 失败等，您很可能需要 >1 个开发分支。但这不是功能分支。
如果您有 100 名开发人员，您可能需要功能分支。 这取决于您的功能的紧密耦合程度以及您的 SCM 流程的总体纪律性，尤其是在构建质量方面。 即使您没有功能分支，您也肯定会有某种分支层次结构。
如果您使用的是 Windows，则需要使用图层和图层。 层层功能分支是天赐之物。 如果 shell 团队因为内核团队引入了一个 bug 而无法高效工作，那就是一个大问题了。
当然，需要采取平衡措施。 一些大型组织的功能分支太过分了。 当功能团队 X 祝福的代码需要几个月的时间才能进入 Y 团队时，合并+集成测试的痛苦将超过您最初试图获得的代码库稳定性。 （因此短语“你的树从 MAIN 开始的深度与你的理智成反比”）并且在每种情况下，版本 N 的树都必须随着其发布的临近而变窄，最终崩溃到只有直接签入该版本的主干的程度。包含在内，并且每个功能分支都有效地针对 N+1。
To me, branching by feature only makes sense when you have a large enough project that you can speak intelligently about the "X feature team" as an independent unit.
Moreover, there are certain size criteria (admittedly fuzzy). If you have 10 developers, you only have 1 feature team as far as I'm concerned -- doesn't matter if two of them are always "the widget dialog guys" or "the database guys." You may very well need >1 development branch if someone is doing a major refactor, making a breaking change to APIs, altering expected behavior such that many BVTs will fail, etc. But that's not a feature branch.
If you have 100 developers, you may need feature branches. It depends how tightly coupled your features are and how disciplined your SCM process is in general, especially with regard to build quality. Even if you don't have feature branches, you'll certainly have some sort of branch hierarchy.
If you're working on Windows, layers & layers of feature branches are a godsend. If the shell team can't be productive because the kernel team introduced a bug, that's a frickin' big problem.
Of course, there's a balancing act to be made. Some large organizations take feature branching too far. When it starts to take months before code blessed by feature team X makes it up to team Y, the pain of merging + integration testing will outweigh the codebase stability you tried to gain in the first place. (hence the phrase "your tree's depth from MAIN is inversely proportional to your sanity") And in every case, the tree for version N must narrow as its release approaches, eventually collapsing to a point where only checkins directly to that release's trunk will be included and every feature branch is effectively targeting N+1.
我什至会更进一步实现 “每个任务分支” 在这里，您对问题跟踪系统中的每个问题使用一个分支（您知道，bugzilla、JIRA 等）。
它可能听起来有点“极端”，但如果您使用支持分支的 SCM，如 Git、Mercurial 或 Plastic（当然，我偏向 Plastic :P），那么它非常容易理解。
I'd even go further and implement "branch per task" where you use a branch for each issue in your issue tracking system (you know, bugzilla, JIRA and so on).
It can sound a little bit "extreme" but it is extremely easy to follow provided you use a branch capable SCM like Git, Mercurial or Plastic (and I'm biased towards Plastic, of course :P)
有时，当冲刺结束时积压的项目尚未准备好发布时，功能分支可以与 Scrum 很好地配合。 你希望避免这种情况，但这种情况必然会时不时地发生。 当这种情况发生时，您只需合并已完成的待办事项列表项，而不合并未完成的待办列表项。 如果需要，未完成的冲刺可以移至下一个冲刺，或者放回待办事项列表中并稍后再处理。 无论如何，您仍然拥有分支，因此您不必丢弃已经提交的代码。
Feature branches work well with Scrum when occasionally a backlog item is not ready for release at the end of the sprint. You hope to avoid that situation, but it is bound to happen from time to time. When it does happen, you simply merge the backlog items that are complete, and don't merge the ones that are not. The one(s) not completed can be moved to the next sprint, if desired, or put back in the backlog and worked later. In any case, you still have the branch, so you don't have to throw away the code you already committed.