这与尝试处理未完成的用户故事有关。一个例子：
在 sprint 1 中，有一个用户故事 #100。因此，我们创建了一个 sprint 分支 (sprint-1)，然后在该分支上创建一个用户故事分支 (us-100)。在冲刺结束时，用户故事还没有完成。正常流程是用户故事使用拉取请求合并到 sprint 分支中，经过审核后，将 sprint 分支合并到开发中（使用拉取请求）。然后删除 sprint 分支。由于 us-100 没有完成，它没有合并到 sprint-1 中，当 sprint-1 被删除时，我不确定 us-100 发生了什么。
我想做的是将us-100 分支“移动”到另一个sprint，例如sprint-2 分支。这可能吗？如何？或者，还有更好的方法？
只需将您的分支重新定位到新的共享 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 分支，您可以照常进行。
您的方法是延迟代码合并，并且很可能将问题隐藏到最后一分钟。
例如，假设您进行审查并决定继续进行代码合并。然后可能会出现合并问题，甚至可能导致需要进行一些重构。此外，这将是您第一次在合并的代码库上运行回归测试。
通过展示实际上仍在进行中的“已完成”故事，确实存在给人以错误印象的风险。
至少我会建议您使用这种方法从头到尾定期合并每个代码分支。这样，您将在进行过程中发现潜在的合并冲突。但是，这并不能减轻回归测试的风险。您也许可以为每个分支进行持续集成构建工作，该工作每晚与 head 合并并针对它运行自动回归测试。