How can I undo a `git commit` locally and on a remote after `git push`

git git-push git-commit

171,067

Solution 1

git reset --hard HEAD~1
git push -f <remote> <branch>

(Example push: git push -f origin bugfix/bug123)

This will undo the last commit and push the updated history to the remote. You need to pass the -f because you're replacing upstream history in the remote.

Solution 2

Generally, make an "inverse" commit, using:

git revert 364705c

then send it to the remote as usual:

git push

This won't delete the commit: it makes an additional commit that undoes whatever the first commit did. Anything else, not really safe, especially when the changes have already been propagated.

Solution 3

First of all, Relax.

"Nothing is under our control. Our control is mere illusion.", "To err is human"

I get that you've unintentionally pushed your code to remote-master. THIS is going to be alright.

1. At first, get the SHA-1 value of the commit you are trying to return, e.g. commit to master branch. run this:

git log

you'll see bunch of 'f650a9e398ad9ca606b25513bd4af9fe...' like strings along with each of the commits. copy that number from the commit that you want to return back.

2. Now, type in below command:

git reset --hard your_that_copied_string_but_without_quote_mark

you should see message like "HEAD is now at ". you are on clear. What it just have done is to reflect that change locally.

3. Now, type in below command:

git push -f

you should see like

"warning: push.default is unset; its implicit value has changed in..... ... Total 0 (delta 0), reused 0 (delta 0) ... ...your_branch_name -> master (forced update)."

Now, you are all clear. Check the master with "git log" again, your fixed_destination_commit should be on top of the list.

You are welcome (in advance ;))

UPDATE:

Now, the changes you had made before all these began, are now gone. If you want to bring those hard-works back again, it's possible. Thanks to git reflog, and git cherry-pick commands.

For that, i would suggest to please follow this blog or this post.

Solution 4

git reset HEAD~1 if you don't want your changes to be gone(unstaged changes). Change, commit and push again git push -f [origin] [branch]

Solution 5

Try using

git reset --hard <commit id>

Please Note : Here commit id will the id of the commit you want to go to but not the id you want to reset. this was the only point where i also got stucked.

then push

git push -f <remote> <branch>

View more solutions

171,067

michael

Updated on July 08, 2022

Comments

michael almost 2 years

I have performed git commit followed by a git push. How can I revert that change on both local and remote repositories?

$ git log
commit 364705c23011b0fc6a7ca2d80c86cef4a7c4db7ac8
Author: Michael Silver <Michael [email protected]>
Date:   Tue Jun 11 12:24:23 2011 -0700

michael almost 13 years

Thanks. I get '$ git reset head~1 fatal: ambiguous argument 'head~1': unknown revision or path not in the working tree.'
Alexander Groß almost 13 years

Alternatively, use git reset --hard <the-sha-you-want-to-return-to>.
dunni almost 13 years

The reference is called HEAD (case sensitive)
Alexander Groß almost 13 years

@dunni, I cannot reproduce case-sensitivity on my system.
Amadan over 10 years

Also, be careful - AFAIK you shouldn't be doing this if other people have pulled from the repo.
Graeck over 10 years

This is a safer (thus probably better) answer than Alexander Groß's (the chosen answer).
Alexander Groß over 10 years

@Graeck Every one of the solutions has its implications and merits.
Bipin Vayalu about 10 years

@AlexanderGroß, is that command directly affect the master branch or working branch ?
Josue Alexander Ibarra about 10 years

This should be the accepted answer, it's best practice never to overwrite history, even more if collaborating with a team. git reset is only accepted if you still have not pushed the changes to the server.
bfcoder about 10 years

@JosueIbarra I disagree for all cases. For most cases, yes, you should not overwrite history. However, I believe that there are legitimate cases where you absolutely should. For instance, you accidentally commit and push up your secrets file. That shouldn't be up in the git repo. So you can quickly remove it using the accepted answer here.
Alexander Groß about 10 years

@BipinVayalu It affects the branch you're currently on. More precisely, the HEAD. The HEAD is most often "attached" to a branch (pointing to a branch name instead of directly pointing to a commit). So, generally speaking, it will affect the branch HEAD points to. Use git log --decorate --oneline to find out where your HEAD points to.
softvar almost 10 years

git reset HEAD~1 if you don't want your changes to be gone(unstaged changes). Change, commit and push again git push -f [origin] [branch]
Alexander Groß over 9 years

@chech I'd like to see what you typed and what was the output. It could be that Git (forcefully) pushed all branches differing from the remote if you have push.default configured to matching.
chech over 9 years

@Alexander Groß fortunately I still have the output. I was in a custom branch and master was reseted too. pastebin.com/97FAkws9
Alexander Groß over 9 years

@chech Yes, that's push.default pushing all branches that have changed w.r.t. origin
Carl-Emil Kjellstrand over 9 years

@bfcoder if you pushed a "secret" to a remote repo, it is no longer a secret. And the proper fix is to create a new secret, not to try to hide your mistake.
crmpicco about 9 years

This only works when your Git repo settings allow history re-writes.
Robson almost 9 years

it is good measure to specify the remote and the branch too when doing "git push -f", but "git push -f" will work anyway most of the time
DarkForce almost 7 years

Just to point out that I tried this answer and it didn't work because my remote branch was protected. Gitlab said that it doesn't allow force push to remote branch. So I had to resort to the answer of @Amadan
scape about 6 years

Just a note, this sha is to be the commit you're reverting from, not to.
larboyer about 4 years

Just note that that's a tilde, not a dash between 'HEAD' and '1'
Speeddymon over 2 years

@Carl-EmilKjellstrand You are partially correct. The issue is not a matter of "hiding the mistake" but rather one of protecting the secret even once it is changed or in the event that the secret cannot be immediately changed (for example, in a production environment). One such case of protecting a secret is where there is secret information ABOUT a secret (such as the secret itself must conform to a limited subset of characters (alphanumeric only)) and you do not want even that information visible in the future to someone who should not have such information.
Carl-Emil Kjellstrand over 2 years

@Speeddymon That is a good point, there might be exceptions as usual :)
Ayan Mitra almost 2 years

you could please condense and make a shorter reply...people wouldnt like reading a novel with unnecesary lines in a coding community