当合并实际完成时，合并提交的Git还原会导致问题。 [英] Git revert of merge commit causes issues when merge is actually done.

问题描述

我们意外地将分支XYZ合并到DEV中，并将其推送到原始库。这是通过--no-ff来创建单独的合并提交。只要我意识到错误的合并，我做了一个git恢复创建恢复提交并将其推出。一切都很好，有很多欢乐......

直到我们试图将XYZ合并到开发者手中为止。最初的困惑是由于许多添加到XYZ的文件不在合并的开发分支上找到的。然后我意识到DEV分支具有恢复提交功能，删除了由于合并而添加到XYZ以及随后添加到DEV的所有文件。

以下是简化的事件：

  $ git checkout dev 
 $ git branch xyz 
 $ git checkout xyz 
 $ git add files / foo.xyz 
 $ git commit -mblargh
  

这里意外的合并发生：

  $ git checkout dev 
 $ git合并xyz 
 $ git push origin dev 
  

这里是我试图保存的日子：

  $ git revert< SHA> 
 $ git push 
  

恢复提交，大家都很开心

  ...更多工作发生... 
  

然后，它终于合并xyz为好：

  $ git checkout xyz 
 $ ls files / foo.xyz 
 files / foo.xyz 
 $ git checkout dev 
 $ git合并xyz 
 $ ls文件/ foo.xyz 
文件未找到
  

所以我的问题是：

a）回滚提交的好方法是什么，特别是如果它们被推送到其他回购站？ git revert似乎是正确的做法，但合并后的问题我不太确定... ...
$ b b b）假设git恢复是正确的方式要做到这一点，如何处理上述合并方案？

PS：我很抱歉如果这个问题已经得到解答，但是我真的不知道要搜索什么。如果有答案，请直接告诉我。谢谢。

解决方案

a）什么是回滚提交的好方法，特别是如果它们被推出到其他回购？ git revert似乎是正确的做法，但合并后的问题我不太确定... ...

如果你已经与其他可能已经拉取该版本的开发人员共享了合并版本，您很确定 git revert 合并提交是正确的。 b>

b）假设git revert是正确的方法，如何处理上述合并方案？

这实际上是git中的一个经典问题。在本帖来自Pro Git博客 - 这个想法，简而言之，就是在再次合并分支之前恢复恢复提交。

更新：还有一个可能也有帮助。

We accidentally merged branch XYZ into DEV and pushed it to the origin repo. This was done with --no-ff to create a separate merge commit. As soon as I realized the wrong merge, I did a git revert to create a revert commit and pushed it out. Everything was good and there was much rejoicing...

Until we tried to merge XYZ into dev for good. Initial confusion was caused by the fact that a lot of files that were added to XYZ were not to be found on the merged dev branch. Then I realized that the DEV branch had the revert commit that deleted all the files that were added to XYZ and subsequently to DEV due to the merge.

Here's the simplified chain of events:

$ git checkout dev
$ git branch xyz
$ git checkout xyz
$ git add files/foo.xyz
$ git commit -m "blargh"

here the accidental merge happens:

$ git checkout dev
$ git merged xyz
$ git push origin dev

and here's me trying to save the day:

$ git revert <SHA>
$ git push

revert commit in place, everybody is happy

... more work happens ...

then, it's finally time to merge xyz for good:

$ git checkout xyz
$ ls files/foo.xyz
files/foo.xyz
$ git checkout dev
$ git merge xyz
$ ls files/foo.xyz
File not found

So my questions are:

a) What's a good way to roll back commits, especially if they have been pushed out to other repos? git revert seemed the right thing to do, but after the merging issues I'm not so sure any more...

b) Assuming that git revert is the correct way to do it, how to handle the above merging scenario?

PS: I apologize if this question was already answered, however I did not really know what to search for. If there is an answer, please direct me to it. Thank you.

解决方案

a) What's a good way to roll back commits, especially if they have been pushed out to other repos? git revert seemed the right thing to do, but after the merging issues I'm not so sure any more...

If you've already shared the merged version with other developers who might have pulled that version, you are quite correct that git reverting the merge commit is the right thing to do.

b) Assuming that git revert is the correct way to do it, how to handle the above merging scenario?

This is actually a classic problem in git. A good (but non-obvious!) way of handling this problem is suggested (and well explained) in this post from the Pro Git blog - the idea, in short, is to revert the revert commit before merging in the branch again.

Update: there's also a another discussion of the same problem by Linux Torvalds that might also be helpful.

这篇关于当合并实际完成时，合并提交的Git还原会导致问题。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！