关于如何在git中处理未完成用户故事的分支的建议

Question

这与试图处理未完成的用户故事有关。举个例子：

在sprint 1中，有一个用户故事#100。因此，我们创建了一个sprint分支(sprint-1)，然后在该分支上创建一个用户故事分支(us-100)。在sprint的末尾，用户故事还没有完成。正常的过程是用户故事使用拉请求合并到sprint分支中，在审查之后，sprint分支被合并到develop中(使用拉请求)。然后删除sprint分支。因为我们-100没有完成，它没有合并到sprint-1，当sprint-1被删除时，我不知道我们是怎么回事-100。

我想要做的是“移动”us-100分支到另一个sprint，例如sprint-2分支。这个是可能的吗？多么?还是有更好的方法？

Answer 1

只需将您的分支重新定位到新的共享sprint分支。

例如：

git checkout us-100
git fetch
git rebase origin/sprint-2
git push -f origin us-100

请注意，使用-f (--force)重写了sprint-2分支的历史。国际海事组织这是正确的做法，但如果有其他人也使用该分支，他们将需要调整，因为他们的版本的sprint-2将是不同的。

他们可以：

git checkout us-100
git fetch
git rebase origin/us-100

现在，sprint-2分支将基于新的sprint分支，您可以像往常一样继续执行它。

Answer 2

您的方法是延迟代码合并，很可能是将问题隐藏到最后一分钟。

例如，假设您进行了检查并决定继续进行代码合并。然后，可能会出现合并问题，甚至可能导致某些重构是必要的。此外，这将是您第一次在合并的代码基上运行回归测试。

有一个真实的风险，给人一种错误的印象，进步，通过展示‘已完成’的故事，实际上仍在进行中。

至少，我建议您使用这种方法定期从头到每个代码分支进行合并。这样，您将在进行过程中发现潜在的合并冲突。不过，这并不能减轻回归测试风险。您也许可以为每个分支创建一个持续的集成构建作业，这些分支每晚与head合并，并对其运行自动回归测试。