最近，我们与我的同事讨论了如何在 Scrum 项目中组织版本控制。更具体地说，分支创建的标准（每个开发人员、每个任务、每个故事、每个 Sprint？）和集成方法。
我认为组织它的一种有用方法是为每个用户故事创建一个分支，这样您就可以在完成后将每个故事集成到可发布的主干中，它还允许您始终拥有一个“可交付版本”在任何时候的应用程序。
因此，如果一个故事无法完成，则可以将其省略，并且不会影响 sprint 发布。 （考虑到集中式工具，如果使用分布式工具，考虑因素可能会有所不同）
我想知道你自己的方法，你喜欢哪种工具，以及你所看到的经验和教训的优缺点。
【问题讨论】：
标签： version-control scrum agile
保持分支协议的轻量级。在 Scrum 中，如果有人想对代码进行分支以处理特定功能，那就让他们去做吧。没有人应该害怕分支。这是 DVCS 的好处之一——人们可以根据需要进行分支，并且不受团队规则或标准的偏见。
在我看来，这是逐案处理的，如果您开始在开发过程中看到模式，然后将它们正式化，以便每个人都在同一个页面上。
只要确保每个开发人员都明白集成和合并他们的更改是他们的责任。这应该将标准设置在大约正确的位置，以确保人们在何时分支代码方面做出正确的调用。
【讨论】：
每个用户故事的分支对我来说听起来有点过分。我们保留一个单一的代码库（主干）并解决这个问题。我们通常会分支的唯一一次是修复当前无法等到常规版本发布的生产问题。
【讨论】：
其实这是一个非常有趣的话题。
我们总是在每个任务创建时强制执行分支，事实上，每个任务（不是故事，而是在 Scrum 计划会议之后分解的实际任务）将至少有一个关联的分支。
您可以在下图中看到它的样子：
这使得鼓励同行评审等事情变得非常容易，因为团队可以检查任务（分支）上的修改内容，即使开发人员决定进行许多中间提交（这是一个非常好的做法！）
下面有许多有用的链接：
【讨论】：
每当我们有一个故事或一组故事威胁要让主分支混乱几天或涉及“许多”开发人员时，我们会为此创建一个分支（不常见，我们会尝试分配任务来避免这种情况，但它确实发生了）作为一种降低风险的事情。我们希望确保主分支始终准备好在每个 sprint 结束时发布，即使这可能意味着我们可能没有在 sprint 之后增加主分支的值。
story/feature/task 分支经常与 master 分支同步，目标是始终在 sprint 结束之前将分支合并回来。
当然，我们都使用 'git'，所以实际上我们总是有一个本地分支来处理，而且我们已经非常擅长与 master 同步，足以避免大爆炸式集成，而且很少足以不会在主分支中留下无用/未使用的代码。
除此之外，我们还提供“branch-by-purpose”（PDF）。我还写了更多关于我们如何做 git here.
【讨论】：
我会在每个版本中使用一个分支，并使用持续集成来防止一个用户故事损害其他用户故事。
【讨论】：
您应该对源版本控制系统进行的唯一更改是将其与持续集成系统集成（如TeamCity 或CruiseControl.NET）。
是的，我知道我并没有真正回答你的问题，但我是认真的。在敏捷软件项目中，您希望能够尽可能频繁地（或能够）向客户发布产品。这就是为什么您需要知道源系统中的任何内容都在工作，或者如果它不工作，为什么它不工作。
【讨论】：
我看不出每个功能的分支如何使您更敏捷或更精简。分行管理的成本太高了。我会争辩说，如果您觉得每个功能都需要一个分支，那么您的故事就太大了。一个故事应该在下一个 scrum 中完成，如果没有，肯定在下一个 scrum 之前完成。因此，如果一个分支只存在 1-2 天，我看不出它有什么用处或它的成本如何偿还。许多人处理一个故事是例行公事，所以我有时会使用一个开发分支供开发人员工作，这样他们就可以每天多次合并代码，同时处理同一个故事，而无需部署代码进行测试（主分支） .理想情况下，您将有如此少的故事在进行中并以如此快的速度完成它们，以至于您只需要 Main 分支而无需其他分支。
【讨论】：