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

Question

我有以下情况:我做了一些提交到我的本地存储库,然后另一个分支(~150提交)的巨大合并到主 - 它有很多冲突.

现在,我想在合并之前将我提交的提交移动到推送之前.

通常情况下,我会使用"rebase -i".

不幸的是,默认行为是打破我所做的一次合并提交,实际上已经将150多个提交添加到单独的提交中(我理解它就像我将使用rebase而不是合并开始) - 这是不好的行为我有几个原因.

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

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

谢谢!

Answer 1

这是我在评论中提到的rerere-train.sh脚本的内容- 基本上它重做了合并,使用了你的分辨率,只是让我们看看它.如果您愿意,可以手动为单个提交手动执行此操作:

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符号表示"不要将其传递到历史记录中",因此不会为您的回购中的所有合并提交执行此操作.)

但是,如果你想做到这一点,你最终应该记录下所需的分辨率.这意味着你可以继续做你的rebase -i,当你遇到冲突时,rerere将重新使用REcorded REsolution.只是一个单挑:它仍然在索引中留下标记为冲突的文件,以便您可以检查它们,并确保它的作用是有意义的.一旦你这样做,git add就像用自己解决冲突一样检查它们,然后照常进行!

该git-rerere联机帮助页包含一个非常好的,冗长的rerere正常使用描述,它不涉及实际调用rerere - 它全部自动完成.并且它没有强调的一个注释:它都是基于冲突困境,因此即使冲突在一个完全不同的地方结束,它也可以重复使用一个解决方案,只要它仍然是相同的文本冲突.