推荐的Scrum Git工作流

每当我读到关于Scrum及其工作原理的文章时，我都会说，特定的功能应该在sprint结束时完成并被认为是可交付的。这些故事在整个冲刺过程中燃烧殆尽

我想知道什么是正确的git设置来实现这一点

目前，我们的开发工作有基于特性的分支。开发人员从开发分支中剪切一个功能分支，处理它并将其合并回开发分支。更新后的开发分支中的代码是否应该推送到QA分支进行测试？或者让其他正在工作的特性合并回dev，然后将所有内容推给QA，这样做明智吗？我这样问是因为我们现在的处境是，在冲刺的最后一天之前，什么都没有真正结束，如果能在整个冲刺过程中看到故事结束，那就太好了。

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

---

这样，qa和开发人员都将忙于他们的工作，不会产生冲突。

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

• 回归测试的自动化程度如何
• 您通常使用的功能的大小
• 您对持续集成的使用
• 你对和的使用

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

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

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

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

---

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

这是一个常见的建议。这甚至可能不是一个坏建议。但这不是对问题的回答，也不是scrum。（编辑：当我站在上面的立场上时，我放弃了反对票，因为OP确实声明了他提出这个问题的原因，这个答案可以很好地解决这个问题。）听起来问题在于你仍然在使用瀑布式思考QA测试。很多地方都是这样，我不是说它不能工作——但它看起来不像教科书上的Scrum（或任何形式的敏捷），因为它不是。