Scrum 推荐的 Git 工作流程

Question

每当我阅读有关 Scrum 以及它应该如何工作的信息时，都应该在 sprint 结束时完成特定功能并将其视为可交付的。这些故事会在整个 sprint 中逐渐消失。

我想知道如何设置适当的 Git 来实现这一点？

我们目前为我们的开发工作提供基于功能的分支。开发人员从 dev 分支中切出一个特性分支，对其进行处理，然后将其合并回 dev 分支。是否应该将更新后的 dev 分支代码推送到 QA 分支进行测试？还是让其他正在工作的功能合并回开发，然后将所有内容推送给 QA 是否明智？我之所以这么问，是因为我们处于 sprint 的最后一天之前什么都没有完成的情况，很高兴看到故事在整个 sprint 中结束。

Answer 1

您采取的方法取决于许多因素：

• 您的回归测试自动化程度如何
• 您通常处理的功能的大小
• 您对持续集成的使用
• 您对feature toggles 和canary releases 之类的使用情况

理想的方法是将正在进行的工作提交到您的主分支。实现这一点的方法是拥有大量良好的持续集成和自动化测试覆盖率。这让您确信提交到主分支的任何代码都不会影响现有功能。

如果您使用功能切换和选择性发布，那么这会进一步降低将所有内容合并到主分支的方法的风险。

这是团队想要持续交付时经常使用的方法。

如果您有手动测试方法或有限的自动测试覆盖率，那么将代码合并到主分支是一种冒险的方法。相反，您可能希望在功能分支中工作。但是，可以通过经常从主分支合并到您的功能分支中来降低合并冲突的风险。这样，随着功能重新组合在一起，问题大多已经得到解决。我建议使用持续集成工具进行这种频繁的合并。

使用上述方法会有所帮助，但在 sprint 中逐步完成功能仍然很困难。要实现这一点，您可能需要开始投资于更自动化的回归测试覆盖率，并普遍提高质量标准（也许通过使用测试驱动的开发方法）。

Answer 2

只是一个建议。 您可以让 qa 处理以前的 sprint 代码。 让我们说。 Sprint 1 - 开发了一些东西。 Sprint 2 - 使用 sprint 1 更改剪切一个分支并将其分配给 qa 进行测试，同时开发人员可以继续进行进一步的开发。 在接下来的 sprint 中重复相同的过程。

这样，质量保证人员和开发人员都将忙于他们的工作而不会发生冲突。