git - 如何在 git merge 之后使用 git rebase -i 而不会搞砸？

我有以下情况:
我向我的本地存储库提交了一些提交，然后将另一个分支(约 150 次提交)大量 merge 到主库中——其中有很多冲突。

现在，我想在推送之前将我在 merge 之前所做的提交移到它之后。

通常，我会使用“rebase -i”。

不幸的是，默认行为是打破我所做的一次 merge 提交，这实际上将另外 150 个提交添加到单独的提交中(我理解这就像我使用 rebase 而不是 merge 开始一样) - 这是不好的行为我有几个原因。

我发现了 rebase 的“-p”标志，它保留了 merge ，并且对此感到非常高兴。
不幸的是，这实际上再次应用了相同的 merge ，并忘记了我在解决冲突方面的辛勤工作。再次 - 不良行为!

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

谢谢!

最佳答案

这是我在评论中提到的 rerere-train.sh 脚本所做的 - 基本上它会重做 merge ，使用您的分辨率，然后让我们重新查看它。如果您愿意，您可以仅为您的单次提交手动执行此操作:

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 中的所有 merge 提交做这件事。)

不管你如何做它的事情，你最终应该记录下所需的分辨率。这意味着您可以继续执行 rebase -i，当您遇到冲突时，rerere 将重新使用记录的解析。提醒一下:它仍然在索引中留下标记为冲突的文件，以便您可以检查它们，并确保它所做的事情有意义。完成后，使用 git add 将它们 checkin ，就像您自己解决了冲突一样，然后照常进行!

git-rerere manpage 包含对 rerere 的正常使用的非常好的、冗长的描述，它从不涉及实际调用 rerere - 这一切都是自动完成的。还有一个它没有强调的说明:它都是基于冲突块的，所以即使冲突最终出现在一个完全不同的地方，它也可以重用解决方案，只要它仍然是相同的文本冲突。

关于git - 如何在 git merge 之后使用 git rebase -i 而不会搞砸？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4152936/