Git revert of merge commit causes issues when merge is actually done.

Question

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.

Answer 1

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.