如何在 `git merge` 之后使用 `git rebase -i` 而不会弄乱事情？

我有以下情况：

1. 我对本地存储库进行了一些提交，然后将另一个分支（约 150 次提交）大量合并到主分支中。这里面有很多冲突。

2. 现在，我想将合并之前所做的提交移到推送之前的提交之后。

通常情况下，我会使用rebase -i for it.

不幸的是，默认行为是破坏我所做的一次合并提交，实际上添加了 150 个提交到 master 到单独的提交中（我理解这就像我一开始就使用 rebase 而不是合并一样）——这是不好的行为对我来说有几个原因。

我很高兴发现-p变基标记，保留合并。 不幸的是，这实际上再次应用了相同的合并，并且忘记了我在解决冲突方面的辛勤工作。再说一次——不良行为！

有我想要的解决方案吗？使用rebase -i合并后重新排序或编辑特定提交，而不必重复我的合并后操作？

Thanks!

这是什么rerere-train.sh http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/rerere-train.sh;hb=HEAD我在评论中提到的脚本确实会重做合并，使用您的分辨率，然后让 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>. (The ^commit符号的意思是“不要将其写入历史”，所以它不会费心这样做all合并在您的存储库中提交。）

无论您如何执行它的操作，您最终都应该记录所需的分辨率。这意味着您可以继续做您的事情rebase -i，当遇到冲突时，rerere 将重新使用 REcorded REsolution。请注意：它仍然会在索引中保留标记为冲突的文件，以便您可以检查它们并确保它所做的事情是有意义的。一旦你这样做了，使用git add签入它们，就好像您自己解决了冲突一样，然后像往常一样继续！

The git-rerere manpage http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html包含对 rerere 正常使用的非常好的、冗长的描述，这并不涉及实际调用 rerere — 这一切都是自动完成的。还有一点它没有强调：它都是基于冲突块，因此即使冲突最终出现在完全不同的地方，只要它仍然是相同的文本冲突，它就可以重用解决方案。