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

问题描述

我有以下情况：
我对本地存储库进行了一些提交，然后将另一个分支（〜150个提交）巨大合并到主设备中 - 它有很多冲突。 p>

现在，我想将我在合并之前提交的一个提交移到推送之前。

通常，我会使用rebase -i。

不幸的是，默认行为是打破我实际上增加了150次提交给master的one-merge-commit （我理解它就像是我会用rebase而不是merge来开始） - 这对我来说是不好的行为，原因有几个。

我发现了' -p'标志为rebase，保留合并，并且非常高兴。
不幸的是，这实际上再次应用了相同的合并，并忘记了我在解决冲突方面所做的所有努力。再次 - 不良行为！

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

谢谢！

解决方案

以下是 rerere-train.sh 脚本我在我的评论中提到了 - 本质上它重做合并，使用你的分辨率，只是让我们看看它。如果您喜欢，您可以手动执行此操作：

  git checkout<合并提交的父项> 
 git merge< merged commit> ＃如果这样干净，我们完成了
 git rerere＃如果rerere.enabled为true，自动完成
 git checkout< merge commit> - 。 ＃检查合并结果中的文件
 git rerere＃自动完成，如果rerere.enabled为true 
 git reset --hard＃擦除合并
 
＃和你会想要跟着git checkout< branch>返回到您所在的位置
  

但您也可以设置 rerere.enabled 为true，并执行这些步骤减去直接调用 git rerere - 并且您将在未来进行设置，并自动运行rerere每当你解决冲突。 这就是我所做的 - 它很棒。

如果您想直接运行脚本，您可能需要使用参数运行它例如 rerere-train.sh ^<合并前的提交> <当前分行> 。 （ ^ commit notation的意思是不要经过这个到历史中，所以它不会为 all 在您的回购中提交。）

然而，如果你有兴趣去做它的事情，你最终应该记录下所需的分辨率。这意味着你可以继续并进行rebase -i，当你遇到冲突时，rerere会重新使用REcorded REsolution。只是提醒一下：它仍然会将索引中标记为冲突的文件留下，以便您可以检查它们，并确保它的确有意义。一旦你这样做，使用 git add 来检查它们，就像你自己解决了冲突一样，然后照常进行！

git -rerere manpage 包含了对rerere正常使用的非常好的，冗长的描述，它并不涉及实际调用rerere - 它都是自动完成的。它没有强调的一个说明：它都基于冲突区域，所以即使冲突在完全不同的地方结束，只要仍然是相同的文本冲突，它就可以重新使用解决方案。

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.

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

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.

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!

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?

Thanks!

解决方案

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

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.

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.)

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!

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合并之后使用git rebase -i而不会搞乱事情？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！