推荐的Scrum Git工作流程

Question

每当我读到Scrum及其工作原理时，都应该完成特定的功能，并在冲刺结束时考虑将其交付。那故事使整个冲刺烧尽了。

我想知道什么是适当的git设置才能实现此目标？

我们目前在开发工作中具有基于功能的分支。开发人员从dev分支切下一个功能分支，对其进行处理，然后将其合并回dev分支。是否应该将更新后的dev分支中的代码推送到QA分支进行测试？还是让其他正在使用的功能合并回开发人员然后将所有内容推送到质量检查是明智的选择？我要问的是，因为我们处于这样一种情况，直到冲刺的最后一天才真正完成，所以很高兴看到整个冲刺中的故事都结束了。

Answer 1

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

通过这种方式，qa和开发人员都将忙于工作而不会发生冲突。

Answer 2

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

• 回归测试的自动化程度
• 您通常使用的功能的大小
• 您对持续集成的使用
• 您对feature toggles和canary releases等事物的使用

理想的方法是让正在进行的工作提交到您的主分支。实现此目的的方法是具有良好的连续集成和自动测试覆盖率。这样您可以放心，提交给main分支的任何代码都不会影响现有功能。

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

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

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

使用上述方法将有所帮助，但是仍然难以通过sprint逐步完成功能。为此，您可能需要开始投资于更自动化的回归测试范围，并通常提高质量标准（也许使用测试驱动的开发方法）。