Menu
git revert <commit_hash> alone won't work. Apparently, -m must be specified.
716
Now, if you have already pushed the merged changes you want to undo to your remote repository, you can right-click on the merge commit and select Revert commit from the context menu. You will then be asked if you want to immediately create a commit.
You can undo a Git merge using the git reset –merge command. This command changes all files that are different between your current repository and a particular commit. There is no “git undo merge” command but the git reset command works well to undo a merge.
The -m option specifies the parent number. This is 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 <[email protected]> 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 in the hope that it helps someone:
git revert -m 1 <commit-hash> git push -u origin master Where <commit-hash> is the commit hash of the merge that you would like to revert, and as stated in the explanation of this answer, -m 1 indicates that you'd like to revert to the tree of the first parent prior to the merge.
The git revert ... line essentially commits your changes while the second line makes your changes public by pushing them to the remote branch.
43
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.
27
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.
git checkout your_branch_name
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"
git reset <commit-hash> (i.e. 3779ab50e72908da92d2cfcd72256d7a09f446ba)
git status to show all the changes that were part of the wrong commit.git reset --hard to revert all those changes.git push -f origin your_branch_name
37
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.
20
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
42
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.
21
If you want to revert a merge commit, here is what you have to do.
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:
git revert <merge commit id> -m 1 which will open a vi console for entering commit message. Write, save, exit, done!Long story:
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.
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.
27
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([email protected]) 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.
20
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 <[email protected]>
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:
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....
43
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?
git log
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>
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
<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!
34
-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.
25
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.
git diff --binary master..master_bk_01012017 > ~/myrevert.patch
git apply --check myrevert.patch
git am --signoff < myrevert.patch
git branch mycodebranch_fix
git checkout mycodebranch_fix
git revert [SHA]
41
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
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
