Question

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

在sprint 1中，有一个用户故事＃100。因此，我们创建一个sprint分支（sprint-1），然后在该分支上创建一个用户故事分支（us-100）。在sprint结束时，用户故事未完成。正常的过程是用户故事使用pull请求合并到sprint分支中，并且在审查之后，sprint分支被合并到develop（使用pull请求）。然后删除sprint分支。由于us-100没有完成，它没有合并到sprint-1中，当sprint-1被删除时，我不确定us-100会发生什么。

我想做的是将us-100分支“移动”到另一个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分支的历史记录。 IMO这是正确的做法，但如果有其他人也在使用该分支，他们将需要调整，因为他们的sprint-2版本现在将是不同的。

他们可以这样做：

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

现在，sprint-2分支将基于您的新sprint分支，您可以照常进行。

Answer 2

您的方法是延迟代码合并，并且很可能在最后一刻之前隐藏问题。

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

通过展示实际上仍在进行中的“已完成”故事，存在冒犯进展错误的真实风险。

至少我建议使用这种方法，你可以从头部到每个代码分支进行定期合并。这样你就会发现潜在的合并冲突。但这并没有减轻回归测试的风险。您可以为每个分支进行持续集成构建作业，该分支每晚与头部合并并对其进行自动回归测试。

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

2 个答案: