我有以下情况：
我对本地存储库进行了一些提交，然后将另一个分支（约 150 次提交）大量合并到主存储库中。里面有很多矛盾。
现在，我想将我在合并之前所做的提交移动到推送之前。
通常，我会使用rebase -i它。
不幸的是，默认行为是打破我所做的一次合并提交，实际上添加了 150 多个提交以掌握到单独的提交中（我理解这就像我要使用 rebase 而不是合并开始）——这是不好的行为对我来说有几个原因。
我很高兴发现-prebase 的标志，它保留了合并。不幸的是，这实际上再次应用了相同的合并，并忘记了我在解决冲突方面的辛勤工作。再次——不良行为！
有我想要的解决方案吗？使用rebase -i合并后重新排序或编辑特定提交，而不必重复我的合并后操作？
谢谢！
这就是我在评论中提到的rerere-train.sh脚本的作用——本质上它会重做合并，使用您的分辨率，然后让 rerere 看到它。如果您愿意，您可以为您的单个提交手动执行此操作：
git checkout <parent of merge commit>
git merge <merged commit> # if this goes cleanly, we're done
git rerere # done automatically if rerere.enabled is true
git checkout <merge commit> -- . # check out the files from the result of the merge
git rerere # done automatically if rerere.enabled is true
git reset --hard # wipe away the merge
# and you'd want to follow with git checkout <branch> to return to where you were
但是您也可以设置rerere.enabled为 true，并执行这些步骤减去直接调用git rerere— 并且您将在未来设置，只要您解决冲突，就会自动运行 rerere。这就是我所做的——太棒了。
如果您想直接运行脚本，您可能需要使用rerere-train.sh ^<commit before the merge> <current branch>. （这个^commit符号的意思是“不要从这里进入历史”，所以它不会为你的 repo 中的所有合并提交而烦恼。）
无论您如何做它的事情，您应该最终记录所需的分辨率。这意味着你可以继续做你的rebase -i，当你遇到冲突时，rerere 将重新使用记录的解决方案。提醒一下：它仍然在索引中留下标记为冲突的文件，以便您可以检查它们并确保它所做的事情是有意义的。完成后，请使用git add检查它们，就好像您自己解决了冲突一样，然后像往常一样继续！
git-rerere联机帮助页包含对正常使用 rerere的非常好的、冗长的描述，它从不涉及实际调用 rerere ——这一切都是自动完成的。还有一个它没有强调的注释：它都是基于冲突的，所以即使冲突最终出现在一个完全不同的地方，它也可以重用一个解决方案，只要它仍然是相同的文本冲突。
我使用rerere-train.sh了用户@Jefromi 的回答。但是我有这个错误：
$ ../rerere-train.sh HEAD
C:\Program Files\Git\mingw64/libexec/git-core/git-sh-setup: line 6: .: git-sh-i18n: file not found
迈克尔·马雷克
git-sh-setup 帮助器显然从未被 git 之外的脚本使用。这在 git 2.10 中变得很明显：
下载旧版本- 2.3.4 便携版后- 我设法开始rerere-train.sh工作。