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

Question

git revert <commit_hash> alone won't work. Apparently, -m must be specified.

Cottager

Take a look at the answer for this question: #2319277 – Hufnagel

Related: Undo a Git merge?. – Ileenileitis

The link here is the best example which illustrates reverting the merged commit : christianengvall.se/undo-pushed-merge-git – Jacy

This is an example of where the design of git does not match the git-flow-ish workflow everyone uses. If you have develop checked out, of course you want to revert the 2-commit feature branch that introduced a bug and not the years long shared dev branch. Feels ridiculous needing to pick it with -m 1. – Roam

Just one other suggestion that never occurred to me before - if one of the branches' list of commits is small, you might feel more comfortable reverting individual commits instead of an entire branch of commits. – Ridgeling

If you're using github, and having problems getting this to work, use Github Desktop, and right click on the commit you want to revert, and choose Revert changes in commit. Note you can also view the commands it's running, to find out how to do it from the command line. – Drill

You can always reset the branch to last commit. $git reset hard SHA of previous commit – Cheeseparing

Answer 1

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 <[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 what you're about to revert do git diff <parent_commit> <commit_to_revert>, in this case:

git diff 8989ee0 8f937c6

and

git diff 7c6b236 8f937c6

However, 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. See the revert-a-faulty-merge How-To for more details." (git-merge man page).

Padang

from two numbers 8989ee0, 7c6b236, which one to go. How would I understand ? – Spirant

After revert, I don't think one will be able to easily correct the code in the source branch and merge again? kernel.org/pub/software/scm/git/docs/howto/… – Archambault

While googling around searching for a better explanation, I found this article which I thought did a great job of going over the details. I discovered after reading that what I was really looking for was the RESET command, followed by a force push. Maybe it'll help someone else. atlassian.com/git/tutorials/… – Snack

@ArupRakshit if you run git log 8989ee0 and git log 7c6b236, you should know the answer. – Pleasure

git log --merges to see all merges and git log --no-merges to see history without mergers. Merging a branch brings in the merged branch history into target and make it hard to make out using plain git log – Crawford

uhh, this answer doesn't really make sense without that full log – Abode

git push --force is discouraged as it can overwrite unintended work on the remote. – Hesperidium

@Archambault that is a nice link. I usually create a patch with git and apply it to the orginal starting point of the reverted branch. This method has worked for me many times (being the git fireworker where I work) – Dich

@Simon how do you identify the patch that you need to apply? Let me know your way, My way is as follows. I generally take the source branch hash and merge it to the destination branch hash (branch out from hash i.e. same hash where it was merged previously). Then resolve conflicts properly. This is like doing the wrong merge correctly now. Then soft reset to the hash of wrong merge i.e. git reset <faulty merge commit hash/branch name>. Whatever unstaged changes you now see in your workspace is the patch that you need to apply. – Archambault

This is not correct at all. I merged a dozen child branches into a staging branch, and then merged that staging branch into a master branch, yet doing what you suggest would only revert one of the child branches. – Skat

What does the number after -m represent? Why does git revert -m 2 not require a commit hash (when I try it I get usage: git revert [<options>] <commit-ish>...)? Should I run git revert 8f937c6 -m 1 and then git revert -m 2. – Melaniamelanic

This was a great answer and worked on removing a merge several commits back. The revert removed only the merge, not the subsequent commits which is what was wanted. Suggestion: gitk gives a good visual of the merge and history. – Nether

very helpful, thanks. would be nice to also mention the need to finally 'git push --force' to publish the reversion to your remote. – Stockmon

This does nothing for me. It just says On branch master - Your branch is up-to-date with 'origin/master'. - nothing to commit, working directory clean – Marcos

git lg is really useful here! It helps to graphically see the merge and makes it easier to trace back which parent you should revert to. – Volplane

the first hash is represent the hash (or the head) of the target branch before its merged. the second hash is represent the source branch before its merged to the target. is this correct? – Vanmeter

git checkout -b backup-branch // Create backup branch git reset --hard 8989ee0 Now your backup branch is having the before the merge changes – Ulu

Why is this so complicated? Git is a nightmare sometimes. – Nonna

“git revert 8f937c6 -m 1 will get you the tree as it was in 8989ee0”—Is that correct? This is the case if you do the revert right after the merge ccommit. But if you do it later then you will revert the changes brought in from the second parent. You won’t reset the tree to 8989ee0. – Aggravate

@ArupRakshit I edited the answer according to your question – Languishment

I normally use Github Desktop to revert commits, even merge commits. It doesn't use any -m option, at least not on the GUI side. I guess it figures that out by itself, possibly intelligently reverting the commits in the merge commit. 😉 – Courland

Why was this horribly over-complicated answer accepted? OP wanted to know how to revert the merge. Getting lost in the weeds about which of the two parent branches are involved is unhelpful. You should have explained to him which of the parents is his original branch, and simply told him to use the appropriate command. Don't just throw the book at him and hope he figures it out all the nuance. – Skat

Answer 2

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.

Insolvency

I believed the git revert command already commited the commit object created. For that not to happen you would have to input the --no-commit flag – Sentinel

As @Sentinel mentionned, the commit is already managed by the first line (I needed a :wq to validate it) so the second line is not necessary. – Armington

this is confusing. there are only 2 lines and no git commit.. can someone please edit. – Ursas

@JayRandom as noted in the comments above, the revert command includes a commit. – Decaffeinate

I've merged branch with conflicts ... this command help me to revert it – Newfeld

I like the simplicity of this answer. I feel like --no-edit is a nice option to mention since not everyone wants to have the surprised of having to deal with writing a commit message associated with the revert. – Schinica

I had to use git push -u origin master --force-with-lease to update remote, thanks. – Hitchcock

Answer 3

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.

Howlett

But you can revert the revert to get them back if really needed. – Werbel

Thanks. Very useful to know as the use case for undoing a merge - due to a bug, say - and then re-merging the entire branch once the bug is fixed, is a common one. – Project

If you are like me and later did want the merge you can either revert the revert, or cherry pick the change you reverted. – Parish

In my situation, I hit the having to 'revert the revert' to get my changes-back-issue. Cherry-picking could be a neater way? I'll try that next time... – Credential

This is super important and should be added as a warning to the other answers. IMO you are not really reversing the merge itself, you are reversing the changes made by the merge. – Chlamys

Answer 4

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

Passageway

what if in the meantime 20 developers pulled the latest dev merge? – Acquiescence

I would not force push a development branch when there are 20 developers in the team using that branch. :) In that case, it is wise to just do a revert commit. – Passageway

This is a very good solution when you are working by yourself or you are certain no other devs pulled the commits you screwed up – Unstopped

Just what I needed after pulling a branch locally by mistake. Thanks !! – Planospore

This answer shows on top by default, but it's a dangerous one. Many people will just follow the steps without reading the note at the bottom. I tried to put the note at the top but it looks like the edit queue is full. – Swine

@AbbasMashayekh what is the note you are talking about ? I have been using this answer and it has worked for me every time. Didn't find any flaw. Am I missing something ? – Nexus

@Nexus I moved the 'Note' from the bottom of the answer to the top, this is what he was talking about. – Passageway

Answer 5

git revert -m 1 <merge-commit>

Knighthood

This answer lacks a lot of details. Maybe that's why it's good. – Boudreaux

@GustavoStraube Was that sarcasm or you actually meant the answer was good? It actually worked for me. – Waly

Why "1"? According to a google search: "We specify the merge using the SHA1 hash of the merge commit. The -m followed by the 1 indicates that we want to keep the parent side of the merge (the branch we are merging into)." source: mijingo.com/blog/reverting-a-git-merge – Bourn

this is the answer. simple, actually works. – Phosphatize

This answer can continue to lean on other Answers that explain when you would want to use 1 and when you wouldn't. – Lonnylonslesaunier

out of the box , this one actually works. – Becky

Even after reading other answers I don't understand what 1 vs 2 means here. 1 worked so that's good enough for me. – Histiocyte

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

Mensuration

Hint: If you are doing this at your company, you might not have permission. – Ancohuma

never do a push -f on a shared repo – Photography

Before you do this, create a backup branch, just in case things don't go the way you expected. – Osuna

I think usually determining commit-hash-before-merge is not straightforward by looking at git log because the commits will be interwoven over time - I wonder if this is always MERGECOMMIT^ (this seems to indicate yes git-tower.com/learn/git/faq/undo-git-merge/… )? – Box

@BaptisteMille-Mathias "never do a push -f on a shared repo" ... IF you don't understand what it does. If you do understand, of course force-pushes are a necessary tool. Let's say it's a good guideline for beginners. – Coremaker

Answer 7

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

Gothard

Answer 8

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.

Crime

The warning about the broadcast should really be more explicit about how horrible an idea this is. This will corrupt everyone's version of that branch and is only really useful if you're working with a remote repository (github/bitbucket) that only you have access to. – Fimbriation

Not as bad as pushing modified config files down stream to production. It won't corrupt, its just a rebranch off an earlier commit, so its a round-about way to move the branches pointer to an earlier version. Hopefully it only impacts the local repository – Crime

this is the best approach imho, it will not mess with attempt to undoing merged commit branches – Craftsman

Answer 9

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.

Wendellwendi

I don't understand parents. I want to revert two merges one of them is last commit and one of them is 3rd from last commit and in between there is another merge by someone else. – Paolapaolina

Answer 10

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.

Aerothermodynamics

Answer 11

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 <[email protected]>
  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 <[email protected]>
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,

Emit

Answer 12

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

Ulu

Answer 13

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

Constantina

Answer 14

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!

Eanes

Answer 15

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

Organize

" I can ever decide to do the merge again.": that is harder to do if you have cherry-picked commits, since they will be duplicated. A rebase would be easier (the rebase would detect the similar commits and skip them: https://mcmap.net/q/21519/-git-cherry-pick-and-datamodel-integrity, https://mcmap.net/q/45906/-git-cherry-pick-creates-duplicate-commits) – Odell

hmm, yes. This problem with cherry picking exists, but in this case the other commits are in the old "dead" branch which I would never merge again and also delete the old branch after a while. " I can ever decide to do the merge again." was related to the merge of "b". – Organize

“I never revert a merge. I just create another branch from the revision where everything was ok”—The question was what to do if you want to revert a commit that was already pushed (implied: without rewriting history). – Aggravate

Answer 16

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.

Dalt

Answer 17

The git documentation about git revert -m provides a link exactly explain this situation:

https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt

Luminance

Answer 18

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

Amberjack

-m1 and -m 2? This is not a self-contained answer. – Aggravate

Answer 19

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

Macilroy

Answer 20

This Works For Me ::

1. Check Out to Branch You want to revert previous (Last) Merge Request.
2. Opem Terminal 3.Run the Command git reset --merge HEAD~1.

Chad

Answer 21

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.

Trailer

Anything that involves force-pushes is a bad idea unless you are the only one using the repo, and you know exactly what you are doing. Reverting with git revert and then possibly reverting the revert with git revert (if you need to bring things back again) is a much safer alternative. – Overpowering