Scrum中的版本控制方法

Question

最近和我的同事一起讨论了如何在Scrum项目中组织版本控制。更具体地说，分支创建的标准（每个开发人员，每个任务，每个故事，每个Sprint？）和集成方法。

我认为组织它的一种有用方法是为每个用户故事创建一个分支，这样您就可以在完成后将每个故事集成到可释放的主干中，并且还允许您始终拥有“可交付的版本”在任何时候的应用程序。

因此，如果一个故事无法完成，它可能会被排除在外并且不会影响sprint版本。 （考虑到集中式工具，如果使用分布式工具，则考虑因素会有所不同）

我想知道你自己的方法，你喜欢哪种工具，以及你从经验和所吸取的教训中看到的利弊。

Answer 1

保持分支协议的轻量级。在Scrum中，如果有人想分支代码来处理特定功能，那么就让他们。没有人应该害怕分支。这是DVCS的一个好处 - 人们在需要时进行分支，并且不会受到团队规则或标准的偏见。

对于我的钱，这是一个个案的基础，如果你开始在开发过程中看到模式，那么将它们形式化，以便每个人都在同一页面上。

确保每个开发人员都了解他们有责任整合和合并他们的更改。这应该设置在正确的位置附近，以确保人们正确调用何时分支代码。

Answer 2

每个用户故事的分支听起来对我来说太过分了。我们保留一个代码库（主干）并解决这个问题。我们通常分支的唯一一次是修复当前的生产问题，这个问题不能等到常规发布。

Answer 3

每当我们有一个故事或一组故事可能会使主分支处于混乱状态几天或涉及“很多”开发人员时，我们会为此创建一个分支（不是很常见，我们会尽力避免这种情况，但它发生）作为一种风险缓解的事情。我们希望确保主分支在每个sprint结束时始终可以发布，即使这可能意味着我们可能没有在sprint之后增加master分支的值。

故事/功能/任务分支经常与主分支同步，目标是始终在冲刺结束之前将分支合并回来。

当然，我们都使用'git'，所以实际上我们总是有一个我们工作的本地分支，我们已经非常善于与master进行同步，足以避免大爆炸集成并且很少不会在主分支中留下无用/未使用的代码。

除此之外，我们做'branch-by-purpose'（PDF）。我还写了一些关于我们如何做git here的文章。

Answer 4

实际上这是一个非常有趣的话题。

我们总是强制执行每个任务创建的分支，事实上，每个任务（不是故事，但在Scrum计划会议之后分解的实际任务）将至少有一个关联分支。

您可以在下图中看到它的外观：

这使得鼓励同行评审非常容易，因为团队可以检查任务（分支）上的修改内容，即使开发人员决定进行多次中间提交（这是一种非常好的做法！）

下面有很多链接可以提供帮助：

1. Task per branch detailed
2. Go Agile in 4 steps!
3. 和screencast about it here。

Answer 5

我会在每个版本中使用一个分支，并使用持续集成来防止一个用户故事损坏其他用户。

Answer 6

您应该对源版本控制系统进行的唯一更改是将其与持续集成系统（例如TeamCity或CruiseControl.NET）集成。

是的，我知道我并没有真正回答你的问题，但我的确是这个意思。在敏捷软件项目中，您希望能够尽可能频繁地将产品发布给客户（或能够）。这就是为什么您需要知道源系统中的任何内容正在工作，或者如果它不工作，为什么它不起作用。

Answer 7

我没有看到每个功能的分支如何让您更敏捷或更精益。分支机构管理的成本太高了。我认为如果你觉得你需要一个分支，那么你的故事就太大了。一个故事应该由下一个scrum完成，如果没有，肯定是下一个。因此，如果一个分支仅存在1-2天，我看不出它是如何有用的或它的成本得到偿还。对于许多人来说，处理一个故事是很常见的，所以我有时会使用开发分支让开发人员工作，以便他们可以合并代码每天多次在同一个故事上工作而不需要部署代码进行测试（主分支） 。理想情况下，你会有很少的故事正在进行中并且如此之快地完成它们，你只需要主分支而不需要其他分支。