How to revert a merge commit that's already pushed to remote branch?

Question

git revert alone won\'t work. -m must be specified, and I\'m pretty confused about it.

Anyone experienced this before?<

Answer 1

You could follow these steps to revert the incorrect commit(s) or to reset your remote branch back to correct HEAD/state.

1. checkout the remote branch to local repo.
   git checkout development

2. copy the commit hash (i.e. id of the commit immediately before the wrong commit) from git log git log -n5

   output:
   

   commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 "Merge branch 'wrong-commit' into 'development'"
   commit f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 "this is a wrong commit"
   commit 3779ab50e72908da92d2cfcd72256d7a09f446ba "this is the correct commit"

3. reset the branch to the commit hash copied in the previous step
   git reset <commit-hash> (i.e. 3779ab50e72908da92d2cfcd72256d7a09f446ba)

4. run the git status to show all the changes that were part of the wrong commit.
5. simply run git reset --hard to revert all those changes.
6. force-push your local branch to remote and notice that your commit history is clean as it was before it got polluted.
   git push -f origin development

Answer 2

To keep the log clean as nothing happened (with some downsides with this approach (due to push -f)):

git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>

'commit-hash-before-merge' comes from the log (git log) after merge.

Answer 3

Sometimes the most effective way to rollback is to step back and replace.

git log

Use the 2nd commit hash (full hash, the one you want to revert back to, before the mistake listed) and then rebranch from there.

git checkout -b newbranch <HASH>

Then delete the old branch, copy the newbranch over in its place and restart from there.

git branch -D oldbranch
git checkout -b oldbranch newbranch

If its been broadcast, then delete the old branch from all repositories, push the redone branch to the most central, and pull it back down to all.

Answer 4

This is a very old thread, but I am missing another in my opinion convenient solution:

I never revert a merge. I just create another branch from the revision where everything was ok and then cherry pick everything that needs to picked from the old branch which was added in between.

So, if the GIT history is like this:

• d
• c
• b <<< the merge
• a
• ...

I create a new branch from a, cherry pick c and d and then the new branch is clear from b. I can ever decide to do the merge of "b" in my new branch again. The old branch becomes deprecated and will be deleted if "b" is not necessary anymore or still in another (feature/hotfix) branch.

The only problem is now one of the very hardest things in computer science: How do you name the new branch? ;)

Ok, if you failed esp. in devel, you create newdevel as mentioned above, delete old devel and rename newdevel to devel. Mission accomplished. You can now merge the changes again when you want. It is like never merged before....

Answer 5

-m1 is the last parent of the current branch that is being fixed, -m 2 is the original parent of the branch that got merged into this.

Tortoise Git can also help here if command line is confusing.

Answer 6

git revert -m 1 <merge-commit>