How to revert a merge commit that's already pu

问题:

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

Anyone experienced this before?

回答1:

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 <[e-mail]>
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

回答2:

Here\'s a complete example in the hope that it helps someone:

git revert -m 1 <commit-hash> 
git commit -m \"Reverting the last commit which messed the repo.\"
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 commit ... line essentially commits your changes while the third line makes your changes public by pushing them to the remote branch.

回答3:

Ben has told you how to revert a merge commit, but it\'s very important you realize that 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.

回答4:

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

回答5:

git revert -m 1 <merge-commit>

回答6:

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.

回答7:

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.

回答8:

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.

回答9:

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!

回答10:

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.