How do I revert a merge commit that has already been pushed to remote?

git revert <commit_hash> alone won't work. Apparentl开发者_开发百科y, -m must be specified.

---

In git revert -m, the -m option specifies the parent number. This is needed because a merge commit has more than one parent, and Git does not know automatically which parent was the mainline, and which parent was the branch you want to un-merge.

When you view a merge commit in the output of git log, you will see its parents listed on the line that begins with Merge:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

In this situation, git revert 8f937c6 -m 1 will get you the tree as it was in 8989ee0, and git revert -m 2 will reinstate the tree as it was in 7c6b236.

To better understand the parent IDs, you can run:

git log 8989ee0 

and

git log 7c6b236

---

Here's a complete example:

git revert -m 1 <commit-hash> 
git push -u origin master

git revert ... commits your changes.

• -m 1 indicates that you'd like to revert to the tree of the first parent prior to the merge, as stated by this answer.

• <commit-hash> is the commit hash of the merge that you would like to revert.

git push ... pushes your changes to the remote branch.

---

Ben has told you how to revert a merge commit, but it's very important you realize that in doing so

"...declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want." (git-merge man page).

An article/mailing list message linked from the man page details the mechanisms and considerations that are involved. Just make sure you understand that if you revert the merge commit, you can't just merge the branch again later and expect the same changes to come back.

---

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

Note: Apply this solution only for your own branch, not for a shared branch.

1. checkout the remote branch to local repo.
   git checkout your_branch_name
2. copy the commit hash (i.e. id of the commit immediately before the wrong commit) from git log git log -n5

should show something like this:

commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 "Merge branch 'wrong-commit' into 'your_branch_name'"
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 your_branch_name

---

git revert -m 1 <merge-commit>

---

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.

---

All the answers already covered most of the things but I will add my 5 cents. In short reverting a merge commit is quite simple:

git revert -m 1 <commit-hash>

If you have permission you can push it directly to the "master" branch otherwise simply push it to your "revert" branch and create pull request.

You might find more useful info on this subject here: https://itcodehub.blogspot.com/2019/06/how-to-revert-merge-in-git.html

---

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.

---

If you want to revert a merge commit, here is what you have to do.

1. First, check the git log to find your merge commit's id. You'll also find multiple parent ids associated with the merge (see image below).

Note down the merge commit id shown in yellow. The parent IDs are the ones written in the next line as Merge: parent1 parent2. Now...

Short Story:

2. Switch to branch on which the merge was made. Then Just do the git revert <merge commit id> -m 1 which will open a vi console for entering commit message. Write, save, exit, done!

Long story:

2. Switch to branch on which the merge was made. In my case, it is the test branch and I'm trying to remove the feature/analytics-v3 branch from it.

3. git revert is the command which reverts any commit. But there is a nasty trick when reverting a merge commit. You need to enter the -m flag otherwise it will fail. From here on, you need to decide whether you want to revert your branch and make it look like exactly it was on parent1 or parent2 via:

git revert <merge commit id> -m 1 (reverts to parent2)

git revert <merge commit id> -m 2 (reverts to parent1)

You can git log these parents to figure out which way you want to go and that's the root of all the confusion.

---

I found good explanation for How To Revert The Merge from this link and I copy pasted the explanation below and it would be helpful just in case if below link doesn't work.

How to revert a faulty merge Alan(alan@clueserver.org) said:

I have a master branch. We have a branch off of that that some developers are doing work on. They claim it is ready. We merge it into the master branch. It breaks something so we revert the merge. They make changes to the code. they get it to a point where they say it is ok and we merge again. When examined, we find that code changes made before the revert are not in the master branch, but code changes after are in the master branch. and asked for help recovering from this situation.

The history immediately after the "revert of the merge" would look like this:

---o---o---o---M---x---x---W
              /
      ---A---B

where A and B are on the side development that was not so good, M is the merge that brings these premature changes into the mainline, x are changes unrelated to what the side branch did and already made on the mainline, and W is the "revert of the merge M" (doesn’t W look M upside down?). IOW, "diff W^..W" is similar to "diff -R M^..M".

Such a "revert" of a merge can be made with:

$ git revert -m 1 M After the developers of the side branch fix their mistakes, the history may look like this:

---o---o---o---M---x---x---W---x
              /
      ---A---B-------------------C---D

where C and D are to fix what was broken in A and B, and you may already have some other changes on the mainline after W.

If you merge the updated side branch (with D at its tip), none of the changes made in A or B will be in the result, because they were reverted by W. That is what Alan saw.

Linus explains the situation:

Reverting a regular commit just effectively undoes what that commit did, and is fairly straightforward. But reverting a merge commit also undoes the data that the commit changed, but it does absolutely nothing to the effects on history that the merge had. So the merge will still exist, and it will still be seen as joining the two branches together, and future merges will see that merge as the last shared state - and the revert that reverted the merge brought in will not affect that at all. So a "revert" undoes the data changes, but it's very much not an "undo" in the sense that it doesn't undo the effects of a commit on the repository history. So if you think of "revert" as "undo", then you're going to always miss this part of reverts. Yes, it undoes the data, but no, it doesn't undo history. In such a situation, you would want to first revert the previous revert, which would make the history look like this:

---o---o---o---M---x---x---W---x---Y
              /
      ---A---B-------------------C---D

where Y is the revert of W. Such a "revert of the revert" can be done with:

$ git revert W This history would (ignoring possible conflicts between what W and W..Y changed) be equivalent to not having W or Y at all in the history:

---o---o---o---M---x---x-------x----
              /
      ---A---B-------------------C---D

and merging the side branch again will not have conflict arising from an earlier revert and revert of the revert.

---o---o---o---M---x---x-------x-------*
              /                       /
      ---A---B-------------------C---D

Of course the changes made in C and D still can conflict with what was done by any of the x, but that is just a normal merge conflict.

---

When you view a merge commit in the output of git log, you will see its parents listed on the line that begins with Merge:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

In this situation, git revert 8f937c6 -m 1 will get you the tree as it was in 8989ee0, and git revert -m 2 will reinstate the tree as it was in 7c6b236.

To better understand the parent IDs, you can run:

git log 8989ee0 

and

git log 7c6b236

Take a backup branch

git checkout -b mybackup-brach

git reset --hard 8989ee0 
git push origin -u mybackup-branch

So now you have the changes before the merge, If everything Okay, checkout into previous branch and reset with backup branch

git reset --hard origin/mybakcup-branhc

---

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

---

The correctly marked answer worked for me but I had to spend some time to determine whats going on.. So I decided to add an answer with simple straightforward steps for cases like mine..

Lets say we got branches A and B.. You merged branch A into branch B and pushed branch B to itself so now the merge is part of it.. But you want to go back to the last commit before the merge.. What do you do?

1. Go to your git root folder (the project folder usually) and use git log

2. You will see the history of recent commits - the commits have commit/author/date properties while the merges also have a merge property - so you see them like this:

   commit: <commitHash> Merge: <parentHashA> <parentHashB> Author: <author> Date: <date>

3. Use git log <parentHashA> and git log <parentHashB> - you will see the commit histories of those parent branches - the first commits in the list are the latest ones

4. Take the <commitHash> of the commit you want, go to your git root folder and use git checkout -b <newBranchName> <commitHash> - that will create a new branch starting from that last commit you've chosen before the merge.. Voila, ready!

---

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

---

A very simple answer if you are looking to revert the change that you pushed just now :

commit 446sjb1uznnmaownlaybiosqwbs278q87
Merge: 123jshc 90asaf


git revert -m 2 446sjb1uznnmaownlaybiosqwbs278q87 //does the work

---

I found creating a reverse patch between two know end-points and applying that patch would work. This presumes that you have created snapshots (tags) off of your master branch or even a back up of your master branch say master_bk_01012017.

Say the code branch you merged into master was mycodebranch.

1. Checkout master.
2. Create a full binary reverse patch between master and your backup. git diff --binary master..master_bk_01012017 > ~/myrevert.patch
3. Check your patch git apply --check myrevert.patch
4. Apply patch with sign-off git am --signoff < myrevert.patch
5. If you will need to bring in this code again once it is fixed, you will need to branch off the reverted master and checkout the fix branch git branch mycodebranch_fix git checkout mycodebranch_fix
6. Here you need to find the SHA key for the revert and revert the revert git revert [SHA]
7. Now you can use your mycodebranch_fix to fix the issues, commit and re-merge into master once done.

---

git doc about git revert -m provide a link exactly explain this: https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt

---

I also faced this issue on a PR that has been merged to the master branch of a GitHub repo.

Since I just wanted to modify some modified files but not the whole changes the PR brought, I had to amend the merge commit with git commit --am.

Steps:

1. Go to the branch which you want to change / revert some modified files
2. Do the changes you want according to modified files
3. run git add * or git add <file>
4. run git commit --am and validate
5. run git push -f

Why it's interesting:

• It keeps the PR's author commit unchanged
• It doesn't break the git tree
• You'll be marked as committer (merge commit author will remain unchanged)
• Git act as if you resolved conflicts, it will remove / change the code in modified files as if you manually tell GitHub to not merge it as-is

---

The accepted answer and some other answers demonstrate how to revert a merge commit using the git revert command. However, there was some confusion regarding the parent commits. This post aims to clarify this with a graphical representation and a real example.

Reverting a merge commit is not straightforward as with git revert <commit-hash>, since Git gets confused when looking back from the merge commit due to its two parent commits. To specify the desired parent, uses the -m flag. As git cannot determine which parent is the mainline and which is the branch to un-merge automatically, so this must be specified.

The iss53 branch was merged into master, creating a Merge Commit, C6. C6 had two parents, C5 and C4.

Need to revert C6 and return the repository to its state at C4. So it must specify which parent to use for the revert command.

• For that check the git log, (here representing actual commit hash with code names from graph)

  > git log
  
  commit C6
  Merge: C4 C5
  Author: Mozz <mozz@example.com>
  Date:   Wed Feb 29 23:59:59 2020 +0100
  
  Merge branch 'iss53' to master
  ...
  

• From git log output, note down the parent IDs that come with Merge: - -. It will be in the format of Merge: parent1 parent2, here Merge: C4 C5.

• The C4 commit is in master branch and we need to revert to that, that is parent 1 and -m 1 is needed here (use git log C4 to verify the previous commits to confirm parent branch).

• Switch to the branch on which the merge was made ( it is the master branch here and we aim to remove the iss53 branch from it )

  Do the git revert with -m 1 flag.

  # To revert to C4 in master branch
  git revert C6 -m 1
  
  # C6 - is the merge commit hash
  

For some other cases, if needed revert to C5,

# revert to C5 in iss53 branch
git revert C6 -m 2

# General
git revert <merge commit id> -m 1 (reverts to parent1)
git revert <merge commit id> -m 2 (reverts to parent2)
# remember to check and verify the parent1 and parent2 with git log command.

Practical example

Created a new branch revert-test on an existing project that has only main branch, The commit graph looks like this now.

(For graphical view of commits use —graph with git log [SO ans ref] OR this more interactive VS code extension - git graph)

Now, I've added some new files, modified existing files, and created separate commits on each branch, then pushed them to the origin. The graph now looks like this:

Then, created a pull request from GitHub and merged revert-test branch to main.

I want to undo the merge commit and go back to the last commit in the main branch - which is 12a7327

Note that the merge commit - 2ec06d9 has two parents now - 12a7327 (in main) and 15bde47 (in revert-test), checking git log now,

> git log

commit 2ec06d9d315a3f7919ffe4ad2c2d7cec8c8f9aa3 (HEAD -> main, origin/main, origin/HEAD)
Merge: 12a7327 15bde47
Author: Akshay <63786863+akshay@users.noreply.github.com>
Date:   Sun Feb 5 00:41:13 2023 +0530

    Merge pull request #1 from Akshay/revert-test
    
    Revert test

To revert the merge commit and get back to 12a7327 need to do,

# To the First parent
git revert 2ec06d9 -m 1

Now a commit message will show in editor that specifies the details, check and verify.

So that creates a Revert commit that does the inverse changes of the merge commit.

Lastly push the changes, Now the merge commit changes gone and the Log will look like,

---

As Ryan mentioned, git revert could make merging difficult down the road, so git revert may not be what you want. I found that using the git reset --hard <commit-hash-prior-to-merge> command to be more useful here.

Once you have done the hard reset part, you can then force push to the remote branch, i.e. git push -f <remote-name> <remote-branch-name>, where <remote-name> is often named origin. From that point you can re-merge if you'd like.