Someone accepted a pull request which they shouldn't have. Now we have a bunch of broken code merged in. How do you undo a pull request? I was just going to revert the changes to the commit just before the merge, but I noticed that it merged in a bunch of commits. So now there are all these commits from this person from days before the merge. How do you undo this?
-
11Despite the advice of the accepted answer, PLEASE do not force-push to a repository if the repo is shared with anyone else. You run the risk of ruining the work others have done, and GitHub may continue to show that pull request as having been merged. Another answer to this question explains a safer way to undo a pull request. – alxndr Jun 10 '14 at 18:04
-
2Note: at least now (June 2014), GitHub proposes "Revert" button in their Pull Request web GUI. See [my answer below](http://stackoverflow.com/a/24459309/6309) – VonC Jun 27 '14 at 19:19
-
1The issue with the revert button is that it creates a new commit as an inverse to the pull request, which means that if you want to eventually merge these changes, using the "Revert" button can make that much more difficult. – FluffySamurai Jul 20 '17 at 15:45
9 Answers
There is a better answer to this problem, though I could just break this down step-by-step.
You will need to fetch and checkout the latest upstream changes like so, e.g.:
git fetch upstream
git checkout upstream/master -b revert/john/foo_and_bar
Taking a look at the commit log, you should find something similar to this:
commit b76a5f1f5d3b323679e466a1a1d5f93c8828b269 Merge: 9271e6e a507888 Author: Tim Tom <tim@tom.com> Date: Mon Apr 29 06:12:38 2013 -0700 Merge pull request #123 from john/foo_and_bar Add foo and bar commit a507888e9fcc9e08b658c0b25414d1aeb1eef45e Author: John Doe <john@doe.com> Date: Mon Apr 29 12:13:29 2013 +0000 Add bar commit 470ee0f407198057d5cb1d6427bb8371eab6157e Author: John Doe <john@doe.com> Date: Mon Apr 29 10:29:10 2013 +0000 Add foo
Now you want to revert the entire pull request with the ability to unrevert later. To do so, you will need to take the ID of the merge commit.
In the above example the merge commit is the top one where it says "Merged pull request #123...".
Do this to revert the both changes ("Add bar" and "Add foo") and you will end up with in one commit reverting the entire pull request which you can unrevert later on and keep the history of changes clean:
git revert -m 1 b76a5f1f5d3b323679e466a1a1d5f93c8828b269

- 1
- 1

- 6,716
- 6
- 41
- 54
-
10This should be the correct answer. There is a reference in the git-revert man page to more details from the git mailing list here https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt – Justin Hamade Aug 13 '14 at 17:36
-
3Why the `git checkout upstream/master -b revert/john/foo_and_bar` ? what does it do exactly? – Magne Aug 22 '14 at 15:54
-
10@Magne - you are creating a new branch to do the revert in, which you can then choose where to merge the reversion. Basically just gives you more control of what to do with the branch. In my case, I submitted a new pull request from this "fixed" branch containing the reversion back to our develop branch, which means my new pull request could also be reverted if necessary. This was done for a release where we decided to pull out the first draft of a feature that was rescheduled. No bad code, just not going in this release. – Daniel Nalbach Oct 30 '14 at 17:55
-
4I learned a hard lesson on this one. We pushed a feature to our develop branch but realized there were data issues and reverted directly on develop. Later when things were fixed, we wanted to add newer develop features back to this branch to test their compatibility with this feature before pushing, so I merged develop back to the feature branch. This also applied the reversion commit, which unwrote every change made to the feature branch. > – Greg Feb 25 '19 at 18:33
-
3
Look at your commit graph (with gitk or a similar program). You will see commits from the pull request, and you will see your own commits, and a merge commit (if it was not a fast-forward merge). You just have to find the last of your own commits before the merge, and reset the branch to this commit.
(If you have the branch's reflog, it should be even easier to find the commit before the merge.)
(Edit after more information in comments:)
I assume the last (rightmost) commit was your wrong merge by pull request, which merged the blue line seen here. Your last good commit would be the one before on the black line, here marked in red:
Reset to this commit, and you should be fine.
This means, in your local working copy do this (after making sure you have no more uncommitted stuff, for example by git stash):
git checkout master
git reset --hard 7a62674ba3df0853c63539175197a16122a739ef
gitk
Now confirm that you are really on the commit I marked there, and you will see none of the pulled stuff in its ancestry.
git push -f origin master
(if your github remote is named origin
- else change the name).
Now everything should look right on github, too. The commits will still be in your repository, but not reachable by any branch, thus should not do any harm there. (And they will be still on RogerPaladin's repository, of course.)
(There might be a Github specific web-only way of doing the same thing, but I'm not too familiar with Github and its pull request managing system.)
Note that if anyone else already might have pulled your master with the wrong commit, they then have the same problem as you currently have, and can't really contribute back. before resetting to your new master version.
If it is likely that this happened, or you simply want to avoid any problems, use the git revert
command instead of git reset
, to revert the changes with a new commit, instead of setting back to an older one. (Some people think you should never do reset with published branches.) See other answers to this question on how to do this.
For the future:
If you want only some of the commits of RogerPaladin's branch, consider using cherry-pick
instead of merge
. Or communicate to RogerPaladin to move them to a separate branch and send a new pull request.

- 249
- 1
- 3
- 13

- 73,284
- 20
- 146
- 210
-
But we have a ton of commits between the merge and his first commit. So like we have the merge commit, our own commits and then another commit by him. It seems like it merged in really old commits of his. – Will Jun 26 '11 at 01:53
-
Yeah, it will merge in everything that is an ancestor of the merged commit (and not already an ancestor of your commit). This should not hinder you from resetting - the commits will not be reordered by themselves, if you did not a rebase afterwards. – Paŭlo Ebermann Jun 26 '11 at 01:59
-
Well I don't really know much about git and I use tortoisegit so I don't know if you can do this with it. When I tried resetting to my last commit it still had his old commits in it. – Will Jun 26 '11 at 02:03
-
Is this github repository public? If so, could you post a link so I could take a look? This might help to find the problem. – Paŭlo Ebermann Jun 26 '11 at 02:07
-
Take a look at the network graph, that should help you visualize what happened and figure out what commit you want to reset to: https://github.com/TShock/TShock/network – Tekkub Jun 26 '11 at 02:26
-
I see the one I have to reset to but I don't want to lose my commits after it. – Will Jun 26 '11 at 02:31
-
Do you have local commits after it, not yet in github? As the graph shows, the github repository does not have anything after the merge. Or is your wrong pull another than the last one? – Paŭlo Ebermann Jun 26 '11 at 02:41
-
I mean I want to save the commits on the black line before the blue line was merged. So the 4 black commits before the merge and after his last commit. – Will Jun 26 '11 at 02:54
-
So do I just reset and start merging in the commits I want to keep? Also thanks a ton for your help, I really appreciate it. – Will Jun 26 '11 at 02:55
-
Yes, reset to the last point on the black line before the merge commit (not to any point before the split). The commands I posted in my last edit should do this. (You might want to use `git branch temp` before starting to keep a reference to the commits locally). Then use `git cherry-pick` to pick the commits you want. (Read the documentation first, of course.) – Paŭlo Ebermann Jun 26 '11 at 03:00
-
Okay just did it. I did have to use 'force' when pushing but it seems to be fixed now. Thank you a lot :D. – Will Jun 26 '11 at 03:08
-
1Yeah, now it looks right (apart from the strange *merge into itself* - but this might be a glitch in the network graph software). :-) I'm glad I could help. – Paŭlo Ebermann Jun 26 '11 at 03:19
-
9I think this maybe problematic if someone has pulled the bad commits and they later on send a pull request that contains the same bad commits, thus they sneak but into the repo. Would it not be safer to create a new commit that reverses the bad commits? That way if the bad commits have been pulled to other branches/forks they will be effectively removed by another pull to that other branch/fork? I'm not stating this as fact, this is what I *think* may be true, being in the same position as the OP and having spent an hour or so considering my options. – Myles McDonnell Dec 17 '12 at 14:40
-
For the love of everyone else you are working with, PLEASE do not force-push to a repo that is shared with anyone else. Search for "force push shared repository" to find some reasons why. The answer started by @errordeveloper (?) explains a better way to do this. – alxndr Jun 10 '14 at 18:00
-
6@Will I would suggest unaccepting this answer. This is fine for code that hasn't been pushed yet (in which case, [this](https://stackoverflow.com/questions/2389361/undo-a-git-merge-that-hasnt-been-pushed-yet?lq=1) is a more relevant SO question, but for code that is shared publicly, doing a git command that rewrites history (in this case, `reset --hard` and a force push is very bad practice). The answer by @errordeveloper below shows a way to do this without any history rewriting or force pushing. – asmeurer Feb 15 '16 at 20:29
-
@Will thanks, that [earned me the populist badge](http://stackoverflow.com/help/badges/62/populist?userid=600500) ;-) – Paŭlo Ebermann Feb 17 '16 at 15:28
-
For the love of Linus Torvalds please dont force push to a shared repository. – hreinn Mar 25 '21 at 17:44
If the pull was the last thing he did then
git reset --hard HEAD~1

- 30,803
- 25
- 102
- 142
-
6be careful following this instruction, it actually set me back 2 steps, not one. – szeitlin Jan 12 '16 at 23:57
-
2@szeitlin How could it happen that it took you back 2 steps, not one? I know this comment was left 4+ years ago but I'm curious if anyone knows an answer how it might happen. This is very important for me. Thanks. – Haradzieniec Jun 03 '16 at 15:33
-
I don't remember now, but I'm guessing it could happen if I had made a new commit when I tried to reset? I would just test it with a dummy repo if you're worried about it. – szeitlin Jun 06 '16 at 16:01
-
This one worked well for me. It deleted the recently merged pull request. After `git reset --hard HEAD~1` , I used `git push origin -f` to update the remote repository. But be careful, take caution before doing this. – Denny Jan 10 '20 at 09:15
Starting June 24th, 2014, you can try cancel a PR easily (See "Reverting a pull request") with:
you can easily revert a pull request on GitHub by clicking Revert:
You'll be prompted to create a new pull request with the reverted changes:
It remains to be tested though if that revert uses -m
or not (for reverting merges as well)
But Adil H Raza adds in the comments (Dec. 2019):
That is the expected behavior, it created a new branch and you can create a PR from this new branch to your
master
.
This way in the future you can un-revert the revert if need be, it is safest option and not directly changing yourmaster
.
Warning: Korayem points out in the comments that:
After a revert, let's say you did some further changes on Git branch and created a new PR from same source/destination branch.
You will find the PR showing only new changes, but nothing of what was there before reverting.
Korayem refers us to "Github: Changes ignored after revert (git cherry-pick
, git rebase
)" for more.
Also:
API for reverting a pull request (Jan. 2023)
A GraphQL mutation is now available for reverting a merged pull request:
revertPullRequest
.Like the revert action on the pull request page in the web, calling this API creates a new pull request that reverses the changes made by the merged pull request.
Learn more about reverting a pull request.

- 1,262,500
- 529
- 4,410
- 5,250
-
1i tried this and it created a new branch instead of undoing PR on master? – Ruslan Mar 15 '17 at 10:31
-
Strange. Could you ask a new question in order to illustrate that behavior? – VonC Mar 15 '17 at 10:35
-
1that is the expected behavior, it created a new branch and you can create a PR from this new branch to your master. This way in the future you can un-revert the revert if need be, it is safest option and not directly changing your master. – Adil H. Raza Dec 05 '19 at 15:02
-
1@AdilH.Raza Thank you. I have included your comment in the answer for more visibility. – VonC Dec 05 '19 at 17:03
-
WARNING: *Github Revert is the mother of all evils*. After a revert, let's say u did some further changes on git branch and created a new PR from same source/destination branch. You'll find the PR showing only new changes, but nothing of what was there before reverting. To know why this happens, check: https://stackoverflow.com/a/35408117 – Korayem Dec 31 '19 at 15:05
-
@Korayem Thank you. I have included your comment in the answer for more visibility. – VonC Dec 31 '19 at 15:24
-
1@VonC fingers crossed this will save developers around the globe from too much agony and time waste – Korayem Feb 09 '20 at 16:53
-
well its 2021 now and I absolutely do not see a Revert button anywhere on the pull request I accidentally just merged.... – ennth Apr 07 '21 at 16:57
-
@ennth Strange: can you report it to GitHub support? (https://support.github.com/request) – VonC Apr 07 '21 at 17:14
-
1
To undo a github pull request with commits throughout that you do not want to delete, you have to run a:
git reset --hard --merge <commit hash>
with the commit hash being the commit PRIOR to merging the pull request. This will remove all commits from the pull request without influencing any commits within the history.
A good way to find this is to go to the now closed pull request and finding this field:
After you run the git reset
, run a:
git push origin --force <branch name>
This should revert the branch back before the pull request WITHOUT affecting any commits in the branch peppered into the commit history between commits from the pull request.
EDIT:
If you were to click the revert button on the pull request, this creates an additional commit on the branch. It DOES NOT uncommit or unmerge. This means that if you were to hit the revert button, you cannot open a new pull request to re-add all of this code.

- 558
- 5
- 9
-
Great way to get things straightened out without needing any crazy reverting or cherry-picking – Cumulo Nimbus Jul 18 '17 at 18:59
-
Thanks! That was what I was planning on doing, but that would have been around ~200 commits to cherry pick out. – FluffySamurai Jul 18 '17 at 19:14
I use this place all the time, thanks.
I was searching for how to undo a pull request and got here.
I was about to just git reset --hard
to "a long time ago" and
do a fast forward back to where I was before doing the pull request.
Besides looking here, I also asked my co-worker what he would do, and he had a typically good answer: using the example output in the first answer above:
git reset --hard 9271e6e
As with most things in Git, if you're doing it some way that's not easy, you're probably doing it wrong.

- 143,130
- 81
- 406
- 459

- 21
- 1
If you want to undo the pull request so we can follow these steps-
List of activities all pull request -
git reflog
After running the above command this output will occur.
then run reset command-
git reset --hard 6954dff92
where 6954dff92 merging id, and your code updated based on the merge id.
Thanks, I hope it will be help, please like and support.

- 127
- 1
- 4
If you give the following command you'll get the list of activities including commits, merges.
git reflog
Your last commit should probably be at 'HEAD@{0}'
. You can check the same with your commit message.
To go to that point, use the command
git reset --hard 'HEAD@{0}'
Your merge will be reverted. If in case you have new files left, discard those changes from the merge.

- 1,045
- 3
- 23
- 46

- 1
- 2
First run this command to get all the merges in the main branch(the branch where the work was merged).
git log --merges
you will get something like this:
commit 125a57ec3bf3eeXXXXXXXXXXXXXXXXXXef347e30 (HEAD -> main,
origin/main)
Merge: b36d5ed7 3d431996
Author: author_name <35093073+author_name@users.noreply.github.com>
Date: Tue Jul 25 11:02:30 2023 +0500
Merge pull request #416 from organization_name/branch_that_was_merged
commit_here
you will find the commit hash here "125a57ec3bf3eeXXXXXXXXXXXXXXXXXXef347e30"(which is 40 digit alphanumeric).Then run the following command.
git revert -m 1 125a57ec3bf3eeXXXXXXXXXXXXXXXXXXef347e30
Using that command your specific commit will be reverted.

- 69,473
- 35
- 181
- 253

- 235
- 1
- 7