如何在 git merge 之后使用 git rebase -i 而不会搞砸? [英] How do I use git rebase -i after git merge without messing things up?

问题描述

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

I have the following situation: I made some commits to my local repository, and then a huge merge of another branch (~150 commits) into the master - it had a lot of conflicts in it.

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

Now, I want to move a commit I made before the merge to be after it before pushing.

通常，我会为它使用rebase -i".

Normally, I would use "rebase -i" for it.

不幸的是，默认行为是打破我所做的一次合并提交，它实际上将另外 150 个提交添加到单独的提交中(我理解这就像我会使用 rebase 而不是合并开始) - 这是出于多种原因，我的不良行为.

Unfortunately, the default behavior is to break the one-merge-commit I did that actually added 150 more commits to master into separate commits (I understand it's like if I would use rebase instead of merge to begin with) - which is bad behavior for me for several reasons.

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

I discovered the '-p' flag for rebase, which preserves merges, and was very happy about it. Unfortunately, this actually applied the same merge again, and forgot all about my hard work in conflict resolving. Again - bad behavior!

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

Is there a solution for what I want? Using rebase -i after merge to re-order or edit specific commits without having to repeat my post-merge operations?

谢谢！

推荐答案

这里是 rerere-train.sh 脚本确实 - 本质上它重做合并，使用您的分辨率，然后让 rerere 看到它.如果您愿意，您可以仅为您的单次提交手动执行此操作:

Here's what the rerere-train.sh script I mentioned in my comment does - essentially it redoes the merge, uses your resolution, and just lets rerere see it. You could do this manually just for your single commit if you like:

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 .这就是我所做的 - 太棒了.

But you could also just set rerere.enabled to true, and do those steps minus the direct calls to git rerere - and you'd be set in the future, with rerere automatically being run whenever you resolve conflicts. This is what I do - it's awesome.

如果您想直接运行脚本，您可能希望使用诸如 rerere-train.sh ^<commit before the merge> 之类的参数运行它.<当前分支>.(^commit 表示法的意思是不要把它带入历史"，所以它不会为你的 repo 中的 all 合并提交而费心这样做.)

If you want to run the script directly, you'll probably want to run it with arguments like rerere-train.sh ^<commit before the merge> <current branch>. (The ^commit notation means "don't walk past this into the history", so it won't bother doing this for all the merge commits in your repo.)

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

However you get rerere to do its thing, you should end up with the desired resolution recorded. That means you can go ahead and do your rebase -i, and when you run into the conflict, rerere will REuse the REcorded REsolution. Just a heads-up: it still leaves the files marked as conflicted in the index, so that you can inspect them, and make sure that what it did makes sense. Once you do, use git add to check them in as if you'd resolved the conflicts yourself, and go on as usual!

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

The git-rerere manpage contains a very nice, lengthy description of normal use of rerere, which doesn't ever involve actually calling rerere - it's all done automatically. And a note it doesn't emphasize: it's all based on conflict hunks, so it can reuse a resolution even if the conflict ends up in a completely different place, as long as it's still the same textual conflict.

这篇关于如何在 git merge 之后使用 git rebase -i 而不会搞砸?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！