我目前正在将 origin/master 重新定位到前一段时间从 origin/master 创建的分支上，而在该分支上工作的开发人员现在不可用。
我已经解决了功能分支的第一次提交时的一些冲突，但到了我必须等待开发人员知道如何完成 rebase 的地步。
有没有办法保持我已经完成的冲突解决（约 30 分钟），以便我可以继续执行另一项任务？
【问题讨论】：
标签： git interactive git-rebase git-stash git-workflow
git stash 所做的只是提交。 （好吧，两次提交，但这并不重要。git stash 的提交位于 no 分支上，并且结构奇怪，但关键是它会提交。那就是因为提交是在 Git 中保存文件的方式。即使是 Git 的 git notes 也是提交！就像存储一样，它们不在分支上，但它们确实保存文件，所以它们是提交。）
如果您可以使用git stash 进行提交，则可以使用git commit 进行提交。
如果没有——如果你还没有完成合并冲突的解决——你基本上就被卡住了。您必须在提交之前解决所有冲突。请参阅How can I save a git "rebase in progress"? 了解更多信息。
请注意，如果您有足够新的 Git 来拥有 git worktree add，您可以设置多个工作树，每个工作树位于不同的分支上。每个工作树都有自己的索引（请参阅其他问题和答案，了解为什么这很重要），因此可以在“the”索引中留下一个正在进行的 rebase 并切换到合并冲突另一个工作树中的另一个分支并执行普通工作。换句话说，“the”索引现在是每个工作树的索引，因此合并冲突在“the”索引中“锁定”了一个工作树，而不是任何其他工作树。
【讨论】：
以后，您可以使用 rerere，它会记录您的决议。这不会立即让你回到 30 分钟的 rebase，但它应该有很大帮助，基本上你只需确认你的决议，直到你停下来。我不知道为什么 rerere 不是 Git 的标准配置，它非常有用。
【讨论】：
另一个脑残的简单解决方案是简单地复制包含 git 存储库的整个文件夹，mid-rebase。这应该始终有效。完成（重新定位和推送）后删除该文件夹可能是个好主意。
【讨论】：
或者另一个想法是提交并在中间重新设置一个分支，然后 git cherry-pick 稍后将未重新设置的提交保留到它上面。
【讨论】：