How do I revert a Git repository to a previous commit?

Created 06.11.2010 16:58
Viewed 7.03M times
7624 votes

How do I revert from my current state to a snapshot made on a certain commit?

If I do git log, then I get the following output:

$ git log
commit a867b4af366350be2e7c21b8de9cc6504678a61b`
Author: Me <>
Date:   Thu Nov 4 18:59:41 2010 -0400

blah blah blah...

commit 25eee4caef46ae64aa08e8ab3f988bc917ee1ce4
Author: Me <>
Date:   Thu Nov 4 05:13:39 2010 -0400

more blah blah blah...

commit 0766c053c0ea2035e90f504928f8df3c9363b8bd
Author: Me <>
Date:   Thu Nov 4 00:55:06 2010 -0400

And yet more blah blah...

commit 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
Author: Me <>
Date:   Wed Nov 3 23:56:08 2010 -0400

Yep, more blah blah.

How do I revert to the commit from November 3, i.e. commit 0d1d7fc?

Related How to undo the last Git commit?. by User, 23.05.2014 17:57
Here's a very clear and thorough post about undoing things in git, straight from Github. by Aurelio, 08.06.2015 19:41
Related: Rollback to an old Git commit in a public repo. Note that that question adds a constraint that the repo is public. by User, 19.10.2015 09:51
I love git, but the fact that there's 35 answers to something that should be incredibly simple exposes a huge issue with git. Or is it the docs? by The Muffin Man, 03.01.2018 22:26
They could add a button functionality for that like SVN in history by IgniteCoders, 13.12.2018 18:29
How is the language "trap" in using the word to revert as colloquially meaning to reset not even adressed here??? 6594 upvotes so far and not an edit in this way, to stress the difference? It wouldn't be more confusing to refer to "saving a file" here with the expression "committing"... by RomainValeri, 07.03.2019 07:28
git reset --hard HEAD~1 by Abrar Jahin, 08.12.2019 05:40
Here's a script that does it, as posted in an answer below: by Brad Parks, 28.02.2020 17:28
Show remaining 3 comments
Answers 41

This depends a lot on what you mean by "revert".

Temporarily switch to a different commit

If you want to temporarily go back to it, fool around, then come back to where you are, all you have to do is check out the desired commit:

# This will detach your HEAD, that is, leave you with no branch checked out:
git checkout 0d1d7fc32

Or if you want to make commits while you're there, go ahead and make a new branch while you're at it:

git checkout -b old-state 0d1d7fc32

To go back to where you were, just check out the branch you were on again. (If you've made changes, as always when switching branches, you'll have to deal with them as appropriate. You could reset to throw them away; you could stash, checkout, stash pop to take them with you; you could commit them to a branch there if you want a branch there.)

Hard delete unpublished commits

If, on the other hand, you want to really get rid of everything you've done since then, there are two possibilities. One, if you haven't published any of these commits, simply reset:

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.

If you mess up, you've already thrown away your local changes, but you can at least get back to where you were before by resetting again.

Undo published commits with new commits

On the other hand, if you've published the work, you probably don't want to reset the branch, since that's effectively rewriting history. In that case, you could indeed revert the commits. With Git, revert has a very specific meaning: create a commit with the reverse patch to cancel it out. This way you don't rewrite any history.

# This will create three separate revert commits:
git revert a867b4af 25eee4ca 0766c053

# It also takes ranges. This will revert the last two commits:
git revert HEAD~2..HEAD

#Similarly, you can revert a range of commits using commit hashes (non inclusive of first hash):
git revert 0d1d7fc..a867b4a

# Reverting a merge commit
git revert -m 1 <merge_commit_sha>

# To get just one, you could use `rebase -i` to squash them afterwards
# Or, you could do it manually (be sure to do this at top level of the repo)
# get your index and work tree into the desired state, without changing HEAD:
git checkout 0d1d7fc32 .

# Then commit. Be sure and write a good message describing what you just did
git commit

The git-revert manpage actually covers a lot of this in its description. Another useful link is this section discussing git-revert.

If you decide you didn't want to revert after all, you can revert the revert (as described here) or reset back to before the revert (see the previous section).

You may also find this answer helpful in this case:
How can I move HEAD back to a previous location? (Detached head) & Undo commits

06.11.2010 17:04
I tried your first method, but then when I went back to master and tried merging the new branch it said Already up-to-date.. I fixed my problem by copying the files from the new branch to and external folder, checking master back out, then copying the files back in manually overwriting everything then git adding and git commiting everything to master. After that I deleted the new (but temporary) branch. by trusktr, 18.03.2012 21:55
Just one thing... how do I come back to head? After doing git checkout 0d1d7fc32?? by Jaime Hablutzel, 14.04.2012 03:15
@jaime By "head" I assume you mean "the branch I previously had checked out? git checkout - checks out the previous think you had checked out; git checkout <branch> would be the explicit way. (As with anything about Git here, please be careful running commands if you don't understand what they do.) by Cascabel, 14.04.2012 06:25
By head I was talking about the commit I was before, the last one by Jaime Hablutzel, 14.04.2012 08:02
You probably had a branch checked out, not just a commit - and you should probably understand the difference before you deliberately detach HEAD again. by Cascabel, 14.04.2012 13:59
@Rod's comment on git revert HEAD~3 as the best wat to revert back 3 commits is am important convention. by New Alexandria, 22.08.2012 15:16
Could you write the whole number? like: git reset --hard 0d1d7fc32e5a947fbd92ee598033d85bfc445a50 by Spoeken, 04.12.2012 13:58
@MathiasMadsenStav Yes, you can of course specify commits by the full SHA1. I used abbreviated hashes to make the answer more readable, and you also tend to use them if you're typing out. If you're copying and pasting, by all means use the full hash. See Specifying Revisions in man git rev-parse for a full description of how you can name commits. by Cascabel, 04.12.2012 16:55
I ran 'git checkout 0d1d7fc32' to go back temporarily. Now how do I get back to the latest? My latest does not show up in 'git log' anymore by Xavier John, 17.01.2013 19:08
You can use git revert --no-commit hash1 hash2 ... and after this just commit every single revert in one commit git commit -m "Message" by Mirko Akov, 24.09.2013 12:12
YOu need to do a git push origin master after revert. by chovy, 16.11.2013 06:54
Git community book link is dead. Is this a good replacement? by James Kingsbery, 17.12.2013 21:30
Why use git stash && git reset --hard && git stash pop? Wouldn't git reset 0d1d7fc32 achieve the same? --mixed is default for reset, which leaves the working tree unstaged as before the reset. by gregers, 14.01.2014 12:49
@gregers Not if some of the modifications are in files that'll have to be reset (they were changed in the commits to be lost in the reset). by Cascabel, 14.01.2014 17:27
@JamesKingsbery It doesn't mention "git revert". by dentarg, 10.02.2014 18:49
Shouldn't git checkout -b old-state 0d1d7fc32 be git checkout 0d1d7fc32 -b old-state instead? by Yarin, 12.02.2014 00:56
@Yarin No. From the usage statements at the top of the man page, paraphrased: git checkout [-b <new_branch>] [<start_point>]. What you wrote might work too, but it's not the normal order of options and arguments, and it's not documented as working. by Cascabel, 12.02.2014 01:27
BTW, if you created some files and then reset, make sure you run git clean -f -d -n to see what files are not tracked, and git clean -f -d to delete them. by nahtnam, 26.04.2014 21:52
What does 'publish' mean in this context? by Howiecamp, 20.08.2014 22:06
@Yarin's answer is safer. Please take a look before you decide what to do. by DrBeco, 23.11.2014 05:31
@DrBeco It's not as simple as safe or not; the answers don't all do the same thing. Yarin's answer is a special case of the last of the options in this answer. by Cascabel, 23.11.2014 06:21
Since OP didn't specified if s/he wants a temporary/unplublished/published revert, your answer is for sure complete and I upvoted it. But the simple way Yarin approaches third option is IMHO far better to use, remember, and avoid errors. Simple is good. by DrBeco, 23.11.2014 18:55
Example I made 3 commits ,c1 C2 C3 in order ,now I realise after C1 everything I did was trash ,so I want to go back to that state and remote the commits upward of C1 completely ie ..file state should be. Restored to C1 and git log should only show C1 and older commits ,using git reset --hard C1ID will be perfect ? ..thanks I'm a git beginner by Sainath S.R, 27.12.2014 18:24
also note that if there are any tags on the commits you are trying to delete you'll want to delete them with git tag -d some-tag-name by schmidlop, 21.02.2015 17:58
How you come back from git checkout 0d1d7fc32 to the head? imagine my latest commit was 0d1d85932. I executed git checkout 0d1d7fc32 but now I want to return where I was. If I execute git checkout 0d1d85932, git says DETACHED HEAD. Thanks by mannuk, 06.03.2015 13:47
so, can anyone tell me how to go back to the latest commit after doing "git checkout 0d1d7fc32" ?? by tyegah123, 10.03.2015 10:56
I don't understand your explanation to @gregers. Even if some files are changed in the commits to be lost, their copies are still in the working tree. I don't see when stashing can be helpful in the scenario of "Hard delete unpublished commits" instead of a simple git reset --mixed. by Loax, 13.05.2015 15:16
Temporarily switch to a different commit - how to switch back? by アレックス, 28.06.2015 09:31
@DonHatch Maybe it's because that wasn't the question, and fully answering that adds in a lot more complexity, while the simple answers are basically "do this again". For example, if you use git revert, then decide you didn't want to, going back to where you were before is equivalent to doing one of the things in this answer again - revert the revert, reset to before the revert, or checkout to before the revert. I can edit a bit, but if you have a different question, ask a new question. by Cascabel, 08.07.2015 22:10
I see you improved the answer to make it closer to as-advertised, thanks :-) This does make your answer more useful, to me and, it looks like, to several others who commented in this thread. I think it might be improved even more if this part of the recipe could be made a bit more explicit, especially for a new/casual user for whom it's not necessarily obvious that they currently have a branch called "master" checked out. Suggestion: "To go back to where you were, just checkout the branch you were on again, using <code>git checkout -</code> or the explicit branch name such as 'master'" by Don Hatch, 09.07.2015 11:44
Note Don't forget to "unprotect" your branch in question when using hard resets on gitlab or github. by ferdy, 16.09.2015 07:32
@Jefromi, after "git checkout 0d1d7fc32 .", is the HEAD already detached? Then "git commit" cannot do anything with the dangled HEAD. by user1914692, 11.11.2015 17:03
@user1914692 No, that doesn't detach HEAD. The . there is important - it directs git to check out the state from 0d1d7fc32 in the current directory, but it leaves HEAD where it was. It's the same as using something like git checkout other-branch path/to/file - that will leave you on your current branch, and just check out the given file. In this case we're checking out the entire current directory instead of just one file, but still not changing HEAD. by Cascabel, 11.11.2015 17:57
@Jefromi Thanks. This is a very useful option. It seems when Git manual talks about "git checkout commit", it does not mention there is another option to add "." to avoid detached HEAD. Is your information from this part: "git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>…​" ? by user1914692, 12.11.2015 17:10
@user1914692 Yes, . is a path. Anything in the git checkout man page about checking out specific paths applies here, including the very first sentence under what you quoted: "When <paths> or --patch are given, git checkout does not switch branches." by Cascabel, 12.11.2015 17:41
@Jefromi The manual says ".. does not switch branches". But it does not say it would not detach HEAD. See my question in the link… , somebody says "If you want to check out a commit that isn't the last commit of any branch, it's fundamentally impossible to check that out while at the same time having HEAD refer to a branch" by user1914692, 12.11.2015 21:42
@user1914692 Detaching HEAD is a subcategory of switching branches. When you detach HEAD, you switch being on a branch to being on no branch. The difference between switching to a branch and detaching head is a difference in destination, but you've still switched away from your current branch. So when that paragraph says it doesn't switch branches, it means HEAD stays the same - if you do git checkout <branch> <path>, it does not switch to that branch, and if you do git checkout <commit> <path> it does not detach HEAD by switching to that commit. by Cascabel, 12.11.2015 22:37
@user1914692 This is all totally consistent with the other question you point to, of course. There is still no way to actually check out a non-branch commit without detaching HEAD. You can check out all the contents of that commit like this, but HEAD is still where it was. If you commit again you'll commit on top of where you were before, not that other commit. You haven't actually checked out another commit. by Cascabel, 12.11.2015 22:38
@Jefromi I am confused now. You said "git checkout <commit> <path> it does not detach HEAD by switching to that commit". Then you said "There is still no way to actually check out a non-branch commit without detaching HEAD." by user1914692, 12.11.2015 22:55
Let us continue this discussion in chat. by Cascabel, 13.11.2015 00:33
As described in the answer, I went back to a previous commit: git checkout 0d1d7fc32, then I fooled around, and now git won't let me come back: Your local changes to the following files would be overwritten by checkout: Quiz2/ViewController.swift Please, commit your changes or stash them before you can switch branches. Aborting--How do I get back? by 7stud, 28.01.2016 05:12
@7stud The answer is exactly the same as if you got that message when switching branches in any other case, but I went ahead and edited in a short bit to address it. You might want to ask a new question if you're confused about how to switch branches. by Cascabel, 28.01.2016 05:40
@Jefromi, If I create a branch to fool around, when I am done I commit, then switch back to master, then delete the branch: git branch -D fool_around How would that work when I go back to a previous commit and fool around? by 7stud, 28.01.2016 06:07
Why are you committing if you're going to delete the branch? Just reset. But if you prefer committing and then losing track of the commit by deleting the branch, okay. You can do that without there being a branch too; you'll lose track of the commit when you switch away. (This is why there's all kinds of warnings and posts about detached HEAD - you're committing somewhere without a branch to keep track of it.) by Cascabel, 28.01.2016 06:11
@Jefromi, Why are you committing if you're going to delete the branch?-- That's the only way I know how to do it. :( In any case, I still need to know how to get back after checking out a previous commit. If you've made changes, as always when switching branches, you'll have to deal with them as appropriate. You could reset to throw them away--How do I do that? by 7stud, 28.01.2016 06:16
Let us continue this discussion in chat. by Cascabel, 28.01.2016 06:22
@tyegah123 git checkout master is right if you're on master. Generally, you can do git checkout <branch name> to get back to most recent commit. And if you make changes in an older commit then try to come back to master, it will tell you the commands to save those changes in a new branch or dump them and return to the most recent code. by user137717, 28.04.2016 16:15
i just use git reset --hard 0d1d7fc32 by raditya gumay, 13.07.2016 02:32
git push -f origin master to fix remote after you've fixed local. by John Erck, 22.08.2016 19:02
Just to note, if you've messed things up doing a merge or just general changes, you'll notice that you can't just do the above. You firstly need to commit your problem files. Just don't push. by Daniel Dewhurst, 03.11.2016 12:22
@Jefromi What if I want to rewrite the history because I don't ever need those changes anymore. I need to go back three commits and I don't want to have anything in front of that desired commit? I'm the only one in the repo so it does not affect to anyone else. What command should I use to throw away all the changes ahead of the commit I want to be? by alexventuraio, 23.11.2016 05:57
@AlexVentura There's a section called "hard delete unpublished commits". by Cascabel, 23.11.2016 06:59
@Jefromi No, but they are already published. I mean they are in the remote. Because I have run git push origin master but now I want to delete de las three commits on my local and then push the changes in order to the remote also COMPLETELY DELETE any commit in front of the desired one. by alexventuraio, 23.11.2016 19:32
@AlexVentura Sounds like you already know you need to just do this, and push. If you've tried that, you should've gotten an error about a non-fast-forward push, which you can override with git push --force. There are a ton of existing questions about this, e.g. by Cascabel, 23.11.2016 19:44
@Jefromi Yes, I have done what you said and I got that error and then I used force. But because I don't have lots of experience with Git I'm not fully convinced, so I'd like to know if that's the right way or if there's a way to confirm and be sure there's nothing in front of my actual commit and just overwrite de history in local and remote? by alexventuraio, 23.11.2016 19:56
@AlexVentura I think you're to the point where you should really be asking a new question. Comments here are for clarifying the existing answer. If you need help examining the contents of repositories, or what commits are on what branches, that's another topic. by Cascabel, 23.11.2016 20:31
3 sections and none of them useful. The real answer is below: git revert --no-commit 0766c053..HEAD by user3690202, 01.01.2017 02:29
git checkout -b old-state 0d1d7fc32 gives me an error fatal: Cannot update paths and switch to branch 'oldApi' at the same time. I had to do it separately by first calling git checkout 0d1d7fc32 and then git checkout -b old-state. by SCBuergel, 19.01.2017 12:30
I'm pretty sure the question is asking how to move the repository back to how it was when commit <XXX> was pushed. SO GIT Questions in particular need to apply moderation in fighting the temptation to over-inform in exhibition of knowledge and intricacy. The question is clear to revert back: not revert back with x,y,z as long as p,q,r,s if you want to switch between a,b,c branches. 1 branch, 1 question, 1 point in time to move back to. by Jordan Stefanelli, 15.08.2017 10:48
@JordanStefanelli Honestly, even from your comment, I don't actually understand which of these options you think the OP would want. And I certainly don't think it was at all clear which of these the OP wanted - "revert" can have a lot of different meanings, and it seemed that the knowledge of a few options, each of which may be the right choice in different situations, would be useful to the OP as well as future readers. I daresay that the acceptance and upvotes have borne this out. by Cascabel, 15.08.2017 15:09
The commit range was especially helpful. Thanks! by Chip Castle, 15.03.2018 14:53
So what if I only want to revert the last published commit - can I do it by git revert HEAD ? by Adam, 27.08.2018 16:03
@Howiecamp published here means the changes have already been committed (locally). by Boooooooooms, 06.04.2020 21:13
git reset --hard <hash value> deleted all files present in .gitignore! There should be a warning about it. by Meet Sinojia, 16.04.2020 11:29
This says git revert HEAD~2..HEAD will revert the last two. Should that be "revert the last three"? I did git revert HEAD~1..HEAD and it reverted the last two. by shaneb, 24.04.2020 14:32
If you use git checkout -b old-state 0d1d7fc32, it create branch in your local and after commiting you changes if you want to push to remote using git push, it will show error fatal: The current branch your-branch has no upstream branch.. Use this to create reference in remote and push it git push --set-upstream origin your-branch. Thanks. by Rana, 09.06.2020 13:36
You can use also patch & apply if your history is too complicated to reverse (e.g several branches merged), and you just want to revert the bare content. git diff <target> | git apply --reverse by Antwan, 20.08.2020 09:20
This answer by Cascabel with 10000+ upvotes, failed me because "git revert HEAD~4..HEAD" did not actually go back 4 commits, it only went back 1 commit. The solution with only 2000 upvotes (and 50 point bounty) managed to revert all 4 of my last commits, in only 1 commit, without deleting history. That one was the answer that was most helpful for me. by user1271772, 13.12.2020 18:43
Is there any way to reset to a commit but to dump all committed changes to the working tree instead of deleting every change made in that commit? by starboy, 18.01.2021 10:26
Show remaining 65 comments

Lots of complicated and dangerous answers here, but it's actually easy:

git revert --no-commit 0766c053..HEAD
git commit

This will revert everything from the HEAD back to the commit hash, meaning it will recreate that commit state in the working tree as if every commit after 0766c053 had been walked back. You can then commit the current tree, and it will create a brand new commit essentially equivalent to the commit you "reverted" to.

(The --no-commit flag lets git revert all the commits at once- otherwise you'll be prompted for a message for each commit in the range, littering your history with unnecessary new commits.)

This is a safe and easy way to rollback to a previous state. No history is destroyed, so it can be used for commits that have already been made public.

12.02.2014 04:18
If you really do want to have individual commits (instead of reverting everything with one big commit), then you can pass --no-edit instead of --no-commit, so that you don't have to edit a commit message for each reversion. by User, 28.06.2014 20:11
If one of the commits between 0766c053..HEAD is a merge then there will be an error popping up (to do with no -m specified). This may help those encountering that:… by timhc22, 21.11.2014 11:55
git newbie here: it seems that if you can't use this command to go back to the most recent commit: I got an "empty commit" message. So you have to commit your latest work and then use this command. I wonder if there's a way of resetting to the last commit? by mike rodent, 13.05.2015 08:17
To see the diffs before you commit use git diff --cached. by John Erck, 06.11.2015 18:35
This did not help; there was a merge and it popped an error saying -m option not specified; As in the comments I did this git revert -m 1 HEAD, and tried again , but it gave an error saying cherrypick or revert is in progress. I did cherrypick --quit, and it went back to the message that there was a merge and -m is not specified by Alex Punnen, 22.02.2016 09:06
I just checked out the commit hash and created a new branch from there to work; This is more safe and easier by Alex Punnen, 24.03.2016 08:59
Also I found I needed to specify the message in the command line using -m "...." otherwise it would try to open VIM and wouldn't be able to save and screw up everything. by Celeritas, 22.05.2016 23:12
$ git revert --no-commit 53742ae..HEAD returns fatal: empty commit set passed by Alex G, 01.08.2016 20:30
This is best answer of this question, it help me to create a commit after full revert back my code to a different tree. by Subho, 12.08.2016 07:14
Indeed, @Celeritas, my one issue with Git (which I otherwise absolutely love) is that single reverts after an unnoticed bad commit/push are hideously (logically) complex to execute. Only a couple command lines, but very dangerous ones... :-) by Brian Knoblauch, 28.09.2016 19:43
If you do not want to commit (just revert state) you should use: git revert --no-edit 6e286400dbe..HEAD, git reset --hard 6e286400dbe so your local repo will be reverted to state of commit 6e286400dbe by maQ, 10.11.2016 11:59
@AlexG that's because you need to enter the hash one before the one that you want to go back to. In my case, hashes were like: 81bcc9e HEAD{0}; e475924 HEAD{1}, ... (from git reflog), and I wanted to undo what I did in 81bcc9e, then I had to do git revert e475924..HEAD by EpicPandaForce, 16.04.2017 14:22
Lots of answers, lots of cases, but it frustrates me to see people call the "revert" option easier and safer. It isn't. They are two different use cases. In any repo with different branches - if you reset a branch, the change will eventually end up everywhere, even in the branch you reset (once the branch is involved in a merge); if you revert a change, the change will eventually be deleted everywhere, not just this branch. If that isn't wanted, this certainly isn't safe. by Cookie, 22.01.2018 16:24
@Cookie - Not following your argument, or what you mean by "if you revert a change, the change will eventually be deleted everywhere". The advantage of using revert is that nothing is deleted, whereas with reset it is. That's why it's safer. by Yarin, 22.01.2018 21:05
Implement feature A in branch A. Merge it to master. Test it. Merge something else. Merge branch A into release. Realize you didn't want to release it yet. Revert it in release. Release is good again. Merge release to master feature A is gone. Merge branch A to master. Merge anything to master. Its still gone. Finally decide to release it. Merge branch A to release. Feature A is still gone. It is gone everywhere and the only way to get it back is to cherry pick all commits or revert the reverts and its a pain. Don't revert when you need to reset. by Cookie, 22.01.2018 21:11
"is a merge but no -m option was given." by Philip Rego, 06.02.2018 20:36
In my opinion, the better approach to git revert --no-commit is git diff <commit-you-want-to-revert-to> > my-diff; patch -R -t -p1 < my-diff. This approach doesn't have the problem about -m option was given, and no history is destroyed either. by Sorawee Porncharoenwase, 07.04.2018 18:30
This yields an error: error: commit d85f9b88d is a merge but no -m option was given. fatal: revert failed by IgorGanapolsky, 22.08.2018 15:13
Question : "How do I revert a Git repository to a previous commit?" With the revert command ! What an idea ! Thanks a lot for this clear, simple, efficient answer and your explanations about consequences of this command. That is this kind of late answer that makes SO the reference. Arg, I would add +10 if I could. by davidxxx, 08.07.2019 08:46
if you want to revert a merge commit. Number 1 can be whatever number you want revert to from parent commit(merge commit) git revert -m 1 <merged-commit-hash> by Viraths, 11.12.2019 04:11
This is the most reasonable syntax and the fact it does not work for merge commits is absolutely awful. by ptkvsk, 09.03.2020 09:56
Worked perfectly for me! by gies0r, 11.04.2020 15:33
It's not easy. This doesn't work for merge commits and most of the time you get conflicts even if you revert a single commit. This is a headache. For merge commits you have to use -m 1 and undo them one by one. Very stupid design from GIT side. by metabuddy, 27.05.2020 08:07
The world needs more people like you, this is perfect, thanks by slothstronaut, 03.07.2020 17:09
The answer by Cascabel with 10000+ upvotes, failed me because "git revert HEAD~4..HEAD" did not actually go back 4 commits, it only went back 1 commit. This solution with only 2000 upvotes managed to revert all 4 of my last commits, in only 1 commit, without deleting history. This one was the answer that was most helpful for me. by user1271772, 13.12.2020 18:42
fatal: bad revision by ScottyBlades, 16.01.2021 05:39
Doesn't git revert --no-commit <hash>" create a new commit? by starboy, 18.01.2021 10:10
error: empty commit set passed fatal: revert failed by JacobIRR, 26.01.2021 22:02
Show remaining 23 comments

Rogue Coder?

Working on your own and just want it to work? Follow these instructions below, they’ve worked reliably for me and many others for years.

Working with others? Git is complicated. Read the comments below this answer before you do something rash.

Reverting Working Copy to Most Recent Commit

To revert to a previous commit, ignoring any changes:

git reset --hard HEAD

where HEAD is the last commit in your current branch

Reverting The Working Copy to an Older Commit

To revert to a commit that's older than the most recent commit:

# Resets index to former commit; replace '56e05fced' with your commit code
git reset 56e05fced 

# Moves pointer back to previous HEAD
git reset --soft HEAD@{1}

git commit -m "Revert to 56e05fced"

# Updates working copy to reflect the new commit
git reset --hard

Credits go to a similar Stack Overflow question, Revert to a commit by a SHA hash in Git?.

21.08.2012 06:19
I did that, but then I wasn't able to commit and push to the remote repository. I want a specific older commit to become HEAD... by Lennon, 24.09.2012 18:17
It means you have already pushed in the commits you wanna revert. It can create lot of problems for people who have checked out your code and working on it. Since they cannot apply your commit smoothly over theirs. In such case better do a git revert. If you are the only one using the repo. Do a git push -f (But think twice before doing that) by vinothkr, 05.12.2012 04:51
I just also want to point out that, alternatively for the soft reset solution, instead of doing a mixed reset first and a hard reset last, you can actually do the hard reset first, as follows: git reset --hard 56e05fc; git reset --soft HEAD@{1}; git commit. by User, 29.06.2014 00:20
If you're working in PowerShell, add quotes around HEAD@{1}: git reset --soft 'HEAD@{1}' because curly braces have a meaning by Amadeusz Wieczorek, 25.08.2014 23:06
Shame a versioning system makes the syntax so complicated for basic history-browsing acitons. by user776686, 17.03.2015 11:57
@nuton linus pauling himself, the creator of git, criticized it for being too complicated. He's on record saying that he was "shocked" git became so popular given its complexity by boulder_ruby, 18.05.2015 23:56
It makes me use vim and I don't know how... so frustrating. by pixelfairy, 28.11.2015 18:29
@pixelfairy, to prevent having to do this, use the -m flag followed by a string in parentheses as your commit comment like so: git commit -a -m 'commit message' by boulder_ruby, 09.02.2016 16:40
Why not just: git reset --hard "(older commit)"? by JobHunter69, 07.08.2016 18:45
@Goldname Doing just the hard reset works fine for local, but breaks down with remote stores on GitHub. You won't be able to update without a pull (which defeats the purpose) due to being behind. The soft/hard reset combo is definitely my preferred as it resolves that issue! by Brian Knoblauch, 28.09.2016 19:38
This answer sucks because it doesn't "work". In a simplistic sense, doing a reset will alter the changes in your local working copy, but then it says that you are 1 commit behind of the truck. Just a recipe for disaster. by user3690202, 01.01.2017 02:26
@boulder_ruby I think you meant Linus Torvalds was the creator of git. But I think Linus Pauling would probably agree that git is complicated. by Suncat2000, 21.02.2018 16:03
Thanks a lot @boulder_ruby! by Alex Bogias, 06.11.2018 12:14
git reset --hard HEAD reverted to the previous commit (as you said), but it also left files in the repo. So strictly speaking it does not revert (precisely) to the previous commit. So, after trying that approach. I have no simply deleted my local copy and cloned the repo. That is not convenient but solves the problem. by stevec, 13.07.2019 09:06
I pushed an update just 30mins before a session with customers and it was a faulty update and doing a simple git reset --hard just saved the day! Thanks! by xperator, 21.02.2021 12:07
Show remaining 10 comments

The best option for me and probably others is the Git reset option:

git reset --hard <commidId> && git clean -f

This has been the best option for me! It is simple, fast and effective!

** Note:** As mentioned in comments don't do this if you're sharing your branch with other people who have copies of the old commits

Also from the comments, if you wanted a less 'ballzy' method you could use

git clean -i
22.10.2013 11:53
Obligatory Warning: don't do this if you're sharing your branch with other people who have copies of the old commits, because using a hard reset like this will force them to have to resynchronize their work with the newly reset branch. For a solution that explains in detail how to safely revert commits without losing work with a hard reset, see this answer. by User, 28.06.2014 20:03
I second @Cupcake's warning... be very aware of the consequences. Note, however, that if your need really is to make those commits disappear from history forever, this reset+clean method will do it, and you'll need for force push your modified branches back to any and all remotes. by ashnazg, 29.10.2014 14:46
remember, clean will remove files/folders such as .idea (phpstorm) or .vagrant (vagrant) which may be used by your set up/IDE! by timhc22, 21.11.2014 11:59
git clean -f DANGER DANGER by Tisch, 16.07.2015 14:59
@Pogrindis - plenty of good answers on here that don't delete untracked files. by Tisch, 17.07.2015 10:29
If you use "git clean -f" I recommend checking first what you'll delete with: git clean -f -n by andreyro, 08.12.2016 14:13
This sets the head of my local copy to the desired commit. But then I cannot push any changes because it is behind the remote. And if I pull from the remote it ends up back where it was at the latest commit on the remote branch. How do I completely obliterate (from everywhere) several commits both on my local copy that have been pushed? by Ade, 22.10.2017 11:47
@Ade .. You could use the git push -f flag.. But be careful, it will override the remote.. Be sure you know what you want to do.. . by Pogrindis, 23.10.2017 09:02
worked only with clean -f. I did not need to save any of my work.. nor did I want to checkin any thing. I just wanted to revert back to a older commit since the build was passing then. by Siddharth, 09.06.2018 07:04
Show remaining 4 comments

Before answering let's add some background, explaining what this HEAD is.

First of all what is HEAD?

HEAD is simply a reference to the current commit (latest) on the current branch. There can only be a single HEAD at any given time (excluding git worktree).

The content of HEAD is stored inside .git/HEAD, and it contains the 40 bytes SHA-1 of the current commit.

detached HEAD

If you are not on the latest commit - meaning that HEAD is pointing to a prior commit in history it's called detached HEAD.

Enter image description here

On the command line it will look like this - SHA-1 instead of the branch name since the HEAD is not pointing to the the tip of the current branch:

Enter image description here

A few options on how to recover from a detached HEAD:

git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

This will checkout new branch pointing to the desired commit. This command will checkout to a given commit.

At this point you can create a branch and start to work from this point on:

# Checkout a given commit.
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# Create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

You can always use the reflog as well. git reflog will display any change which updated the HEAD and checking out the desired reflog entry will set the HEAD back to this commit.

Every time the HEAD is modified there will be a new entry in the reflog

git reflog
git checkout HEAD@{...}

This will get you back to your desired commit

Enter image description here

git reset HEAD --hard <commit_id>

"Move" your head back to the desired commit.

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.
  • Note: (Since Git 2.7) you can also use the git rebase --no-autostash as well.

This schema illustrates which command does what. As you can see there reset && checkout modify the HEAD.

Enter image description here

05.02.2015 21:56
Excellent hint to git reflog, that's exactly what I needed by smac89, 13.03.2016 21:25
Ouch! This all seems awfully complicated... isn't there a simple command that just takes you a step back in the process? Like going from version 1.1 in your project back to version 1.0? I'd expect something like: git stepback_one_commit or something.... by Kokodoko, 20.03.2016 14:35
there is: git reset HEAD^ --hard` by CodeWizard, 20.03.2016 14:38
@Kokodoko Yes, it is horribly complicated... and a perfect example of how little consideration experts have for people who are just starting out. Please refer to my answer here, and also to the book I recommend in it. Git is NOT something you can just pick up intuitively. And I can be absolutely certain CodeWizard didn't do so. by mike rodent, 29.08.2016 17:17

If you want to "uncommit", erase the last commit message, and put the modified files back in staging, you would use the command:

git reset --soft HEAD~1
  • --soft indicates that the uncommitted files should be retained as working files opposed to --hard which would discard them.
  • HEAD~1 is the last commit. If you want to rollback 3 commits you could use HEAD~3. If you want to rollback to a specific revision number, you could also do that using its SHA hash.

This is an extremely useful command in situations where you committed the wrong thing and you want to undo that last commit.


04.03.2014 17:25
This is soft and gently: risk free if you haven't pushed your work by nilsM, 18.01.2017 10:04

You can do this by the following two commands:

git reset --hard [previous Commit SHA id here]
git push origin [branch Name] -f

It will remove your previous Git commit.

If you want to keep your changes, you can also use:

git reset --soft [previous Commit SHA id here]

Then it will save your changes.

12.12.2014 06:52
I tried 1/2 a dozen answers in this post until I got to this one .. all of those others, my git config kept giving me an error when trying to push. This answer worked. Thanks! by Gene Bo, 16.09.2016 19:47
One detail for me was that I lost the diffs .. which I wanted to keep to see what I had done in the commit that didn't work. So next time I would just save that data before issuing this reset command by Gene Bo, 16.09.2016 19:49
This was the only way for me to undo a bad merge, revert didn't work in that case. Thanks! by Dave Cole, 19.01.2017 20:07
Best answer. Thanks by Imran Pollob, 04.08.2019 06:08

I have tried a lot of ways to revert local changes in Git, and it seems that this works the best if you just want to revert to the latest commit state.

git add . && git checkout master -f

Short description:

  • It will NOT create any commits as git revert does.
  • It will NOT detach your HEAD like git checkout <commithashcode> does.
  • It WILL override all your local changes and DELETE all added files since the last commit in the branch.
  • It works only with branches names, so you can revert only to latest commit in the branch this way.

I found a much more convenient and simple way to achieve the results above:

git add . && git reset --hard HEAD

where HEAD points to the latest commit at you current branch.

It is the same code code as boulder_ruby suggested, but I have added git add . before git reset --hard HEAD to erase all new files created since the last commit since this is what most people expect I believe when reverting to the latest commit.

29.07.2012 11:01

The best way is:

git reset --hard <commidId> && git push --force

This will reset the branch to the specific commit and then will upload the remote server with the same commits as you have in local.

Be careful with the --force flag as it removes all the subsequent commits after the selected commit without the option to recover them.

25.02.2020 17:00
I downvoted because I fail to see how your answer provides any new information not already given in for example, or In fact most commits already mention git reset --hard, and many more mention using --force or -f to push. by Alex Telon, 24.03.2020 12:26
It does the work with just one command, clear and simple. You are free to downvote my answer if you don't like it. by david.t_92, 26.03.2020 11:22
Another option to consider for the future is to suggest an edit on an earlier answer or adding a comment saying that 'this can also be done in one line by using &&' for instance. That way everyone can then see the improved answer in one place. by Alex Telon, 27.03.2020 19:40
This is the best answer I am looking for. Thanks - I can't believe everyone is giving confusing responses. by chad, 01.03.2021 21:32
This is the one that did it for me. It's like looking a truly reverted set of commits, where nothing confusing is occurring afterward. Really like going back in time. Thanks. by RootHouston, 04.03.2021 00:54

OK, going back to a previous commit in Git is quite easy...

Revert back without keeping the changes:

git reset --hard <commit>

Revert back with keeping the changes:

git reset --soft <commit>

Explanation: using git reset, you can reset to a specific state. It's common using it with a commit hash as you see above.

But as you see the difference is using the two flags --soft and --hard, by default git reset using --soft flag, but it's a good practice always using the flag, I explain each flag:


The default flag as explained, not need to provide it, does not change the working tree, but it adds all changed files ready to commit, so you go back to the commit status which changes to files get unstaged.


Be careful with this flag. It resets the working tree and all changes to tracked files and all will be gone!

I also created the image below that may happen in a real life working with Git:

Git reset to a commit

20.07.2017 15:55
The default of git reset is git reset --mixed, not git reset --soft. Please check What's the difference between git reset --mixed, --soft, and --hard? and In plain English, what does “git reset” do? by Fabio says Reinstate Monica, 09.04.2020 13:48

Assuming you're talking about master and on that respective branch (that said, this could be any working branch you're concerned with):

# Reset local master branch to November 3rd commit ID
git reset --hard 0d1d7fc32e5a947fbd92ee598033d85bfc445a50

# Reset remote master branch to November 3rd commit ID
git push -f origin 0d1d7fc32e5a947fbd92ee598033d85bfc445a50:master

I found the answer from in a blog post (now no longer exists)

Note that this is Resetting and Forcing the change to the remote, so that if others on your team have already git pulled, you will cause problems for them. You are destroying the change history, which is an important reason why people use git in the first place.

Better to use revert (see other answers) than reset. If you're a one man team then it probably doesn't matter.

10.05.2016 17:21
How is this answer any different than the myriad of others? by Matsmath, 10.05.2016 17:46
That's unfortunate. I emailed the blogger - hopefully he still has it! by markreyes, 04.07.2016 19:29
The push syntax is missing from most other suggestions for how to fix this. Worked great. by jpa57, 24.03.2017 16:20

Say you have the following commits in a text file named ~/commits-to-revert.txt (I used git log --pretty=oneline to get them)


Create a Bash shell script to revert each of them:

cd /path/to/working/copy
for i in `cat ~/commits-to-revert.txt`
    git revert $i --no-commit

This reverts everything back to the previous state, including file and directory creations, and deletions, commit it to your branch and you retain the history, but you have it reverted back to the same file structure. Why Git doesn't have a git revert --to <hash> is beyond me.

13.10.2011 21:51
You could do a git revert HEAD~3 to remove the last 3 commits by Rod, 19.02.2012 18:59
@Rod - No, that's not right. That command will revert the commit that is the third grandparent of HEAD (not the last three commits). by kflorence, 11.09.2012 22:13
@kflorence Ok thanks for the info. Would git revert -n master~3..master~1 work ? (As seen from by Rod, 12.09.2012 01:59
@Rod - That sounds right, sure is an ugly syntax though isn't it? I've always found checking out the commit I want to "revert" to and then committing that more intuitive. by kflorence, 01.10.2012 01:12
@kflorence doesn't that require you to make a new branch though? by Mike Vella, 20.08.2013 11:29
@Lance I agree with you about git revert --to - this seems like an unbelievably complex way to achieve quite a simple thing! by Mike Vella, 20.08.2013 11:31
@MikeVella Nope, no need to create a new branch. by kflorence, 21.08.2013 00:21
There's a much easier way to do this now than with a script like this, just use git revert --no-commit <start>..<end>, because git revert accepts a commit range in new (or all?) versions of Git. Note that the start of the range isn't included in the revert. by User, 28.06.2014 20:02
You could also do git log --no-merges --since "june 1" --format="%h" | xargs git revert --no-edit by Murariu Serban, 18.09.2019 13:57
Script from Lance worked beautifully for me. Thanks! by Mamun, 21.12.2020 18:41
Show remaining 5 comments

Extra Alternatives to Jefromi's Solutions

Jefromi's solutions are definitely the best ones, and you should definitely use them. However, for the sake of completeness, I also wanted to show these other alternative solutions that can also be used to revert a commit (in the sense that you create a new commit that undoes changes in previous commit, just like what git revert does).

To be clear, these alternatives are not the best way to revert commits, Jefromi's solutions are, but I just want to point out that you can also use these other methods to achieve the same thing as git revert.

Alternative 1: Hard and Soft Resets

This is a very slightly modified version of Charles Bailey's solution to Revert to a commit by a SHA hash in Git?:

# Reset the index to the desired commit
git reset --hard <commit>

# Move the branch pointer back to the previous HEAD
git reset --soft HEAD@{1}

# Commit the changes
git commit -m "Revert to <commit>"

This basically works by using the fact that soft resets will leave the state of the previous commit staged in the index/staging-area, which you can then commit.

Alternative 2: Delete the Current Tree and Replace with the New One

This solution comes from svick's solution to Checkout old commit and make it a new commit:

git rm -r .
git checkout <commit> .
git commit

Similarly to alternative #1, this reproduces the state of <commit> in the current working copy. It is necessary to do git rm first because git checkout won't remove files that have been added since <commit>.

29.06.2014 17:51
About Alternative 1, one quick question: By doing so we don't loose in between commits right? by Bogac, 02.12.2014 10:14
@Bogac - the dots indicate a file path, in this case the current directory, so it's assumed you're running it from the root of your working copy. by Tom, 02.12.2014 19:06
The warning is repeated several times in the answer, but could someone add why these are not the best way — compared, to something like git revert HEAD~2..HEAD from @Cascabel's (@Jefromi's) linked solution. I'm not seeing the problem. by Joshua Goldberg, 28.12.2018 02:16

Here is a much simpler way to go back to a previous commit (and have it in an uncommited state, to do with it whatever you like):

git reset HEAD~1

So, no need for commit ids and so on :)

29.02.2016 08:40
didnt work, a git pull after this yields: error: Your local changes to the following files would be overwritten by merge: by malhal, 05.11.2016 00:21
@malhal That is because you've had uncommited changes. Stash/reset them and then it will work without that error. by Paul Walczewski, 22.01.2017 13:37

There is a command (not a part of core Git, but it is in the git-extras package) specifically for reverting and staging old commits:

git back

Per the man page, it can also be used as such:

# Remove the latest three commits
git back 3
08.08.2013 18:30

After all the changes, when you push all these commands, you might have to use:

git push -f ...

And not only git push.

05.09.2013 14:03
Obligatory Warning: don't do this if you're sharing your branch with other people who have copies of the old commits, because using a force push like this will force them to have to resynchronize their work. For a solution that explains in detail how to safely revert commits without losing work with a force push, see this answer. by User, 28.06.2014 20:00
Sometimes this is what you want. Example: committed and pushed several commits to the wrong branch (branch A). After cherry-picking to branch B, I want these commits removed from branch A. I would not want to revert, since the revert would later get applied when branch A and B are merged together. Doing a reset --hard <commitId> in branch A followed by a force push removes these commits from the branch while preserving them in branch B. I can get away with this because I know nobody else is developing on branch A. by Doug R, 22.10.2014 20:44
Thanks! I couldn't figure out how to get the remote branch to match my local branch, Just needed to do a force push. by Mido, 06.02.2017 12:49

You can complete all these initial steps yourself and push back to the Git repository.

  1. Pull the latest version of your repository from Bitbucket using the git pull --all command.

  2. Run the Git log command with -n 4 from your terminal. The number after the -n determines the number of commits in the log starting from the most recent commit in your local history.

    $ git log -n 4
  3. Reset the head of your repository's history using the git reset --hard HEAD~N where N is the number of commits you want to take the head back. In the following example the head would be set back one commit, to the last commit in the repository history:

  4. Push the change to Git repository using git push --force to force push the change.

If you want the Git repository to a previous commit:

git pull --all
git reset --hard HEAD~1
git push --force
06.04.2017 12:20

Select your required commit, and check it by

git show HEAD
git show HEAD~1
git show HEAD~2 

till you get the required commit. To make the HEAD point to that, do

git reset --hard HEAD~1

or git reset --hard HEAD~2 or whatever.

26.02.2014 12:52
Obligatory Warning: don't do this if you're sharing your branch with other people who have copies of the old commits, because using a hard reset like this will force them to have to resynchronize their work with the newly reset branch. For a solution that explains in detail how to safely revert commits without losing work with a hard reset, see this answer. by User, 28.06.2014 19:57
Also, to be clear, git show HEAD is equivalent to just using git log HEAD -1. by User, 28.06.2014 19:58

Revert to most recent commit and ignoring all local changes:

git reset --hard HEAD
26.07.2016 13:13

If the situation is an urgent one, and you just want to do what the questioner asked in a quick and dirty way, assuming your project is under a directory called, for example, "my project":

QUICK AND DIRTY: depending on the circumstances, quick and dirty may in fact be very GOOD. What my solution here does is NOT replace irreversibly the files you have in your working directory with files hauled up/extracted from the depths of the git repository lurking beneath your .git/ directory using fiendishly clever and diabolically powerful git commands, of which there are many. YOU DO NOT HAVE TO DO SUCH DEEP-SEA DIVING TO RECOVER what may appear to be a disastrous situation, and attempting to do so without sufficient expertise may prove fatal.

  1. Copy the whole directory and call it something else, like "my project - copy". Assuming your git repository ("repo") files are under the "my project" directory (the default place for them, under a directory called ".git"), you will now have copied both your work files and your repo files.

  2. Do this in the directory "my project":

    .../my project $ git reset --hard [first-4-letters&numbers-of-commit's-SHA]

This will return the state of the repo under "my project" to what it was when you made that commit (a "commit" means a snapshot of your working files). All commits since then will be lost forever under "my project", BUT... they will still be present in the repo under "my project - copy" since you copied all those files - including the ones under .../.git/.

You then have two versions on your system... you can examine or copy or modify files of interest, or whatever, from the previous commit. You can completely discard the files under "my project - copy", if you have decided the new work since the restored commit was going nowhere...

The obvious thing if you want to carry on with the state of the project without actually discarding the work since this retrieved commit is to rename your directory again: Delete the project containing the retrieved commit (or give it a temporary name) and rename your "my project - copy" directory back to "my project". Then maybe try to understand some of the other answers here, and probably do another commit fairly soon.

Git is a brilliant creation but absolutely no-one is able to just "pick it up on the fly": also people who try to explain it far too often assume prior knowledge of other VCS [Version Control Systems] and delve far too deep far too soon, and commit other crimes, like using interchangeable terms for "checking out" - in ways which sometimes appear almost calculated to confuse a beginner.

To save yourself much stress, learn from my scars. You have to pretty much have to read a book on Git - I'd recommend "Version Control with Git". Do it sooner rather than later. If you do, bear in mind that much of the complexity of Git comes from branching and then remerging: you can skip those parts in any book. From your question there's no reason why people should be blinding you with science.

Especially if, for example, this is a desperate situation and you're a newbie with Git!

PS: One other thought: It is (now) actually quite simple to keep the Git repo in a directory other than the one with the working files. This would mean you would not have to copy the entire Git repository using the above quick & dirty solution. See the answer by Fryer using --separate-git-dir here. Be warned, though: If you have a "separate-directory" repository which you don't copy, and you do a hard reset, all versions subsequent to the reset commit will be lost forever, unless you have, as you absolutely should, regularly backed up your repository, preferably to the Cloud (e.g. Google Drive) among other places.

On this subject of "backing up to the Cloud", the next step is to open an account (free of course) with GitHub or (better in my view) GitLab. You can then regularly do a git push command to make your Cloud repo up-to-date "properly". But again, talking about this may be too much too soon.

19.03.2015 17:33

Caution! This command can cause losing commit history, if user put the wrong commit mistakenly. Always have en extra backup of your git some where else just in case if you do mistakes, than you are a bit safer. :)

I have had a similar issue and wanted to revert back to an earlier commit. In my case I was not interested to keep the newer commit, hence I used Hard.

This is how I did it:

git reset --hard CommitId && git clean -f

This will revert on the local repository, and here after using git push -f will update the remote repository.

git push -f

For instance, if you want to completely ignore the commit with the name enforce non-group manage policies from the next image

enter image description here

you'd run

git reset --hard dd52eb9 && git clean -f

followed by

git push -f

After, you won't see that commit (enforce non-group manage policies) there

enter image description here

08.01.2018 14:15
@Tiago Martins Peres 李大仁 kind of you for editing and adding the example :) by maytham-ɯɐɥʇʎɐɯ, 23.03.2021 19:20
You're welcome! In fact I was in need of it this morning. Once I've gone through the list of all available answers knew right away which one to go with and, as expected, it delivered what was promised. Thank you for that too! 😉 by Tiago Martins Peres 李大仁, 23.03.2021 19:55

This is one more way to directly reset to a recent commit

git stash
git stash clear

It directly clears all the changes that you have been making since the last commit.

PS: It has a little problem; it also deletes all you recently stored stash changes. Which I guess in most cases should not matter.

05.05.2016 11:43
NOTE: New files not added in index are not stashed. You have too add them or manually delete them. by andreyro, 08.12.2016 14:08
Why oh why clearing stash? In addition to being a non-solution, this is actually harmful. Reading the very first sentence of the question immediately invalidates the stash solution (which could be useful ONLY to reset to the LAST commit). by RomainValeri, 07.03.2019 07:35

To completely clean a coder's directory up from some accidental changes, we used:

git add -A .
git reset --hard HEAD

Just git reset --hard HEAD will get rid of modifications, but it won't get rid of "new" files. In their case they'd accidentally dragged an important folder somewhere random, and all those files were being treated as new by Git, so a reset --hard didn't fix it. By running the git add -A . beforehand, it explicitly tracked them all with git, to be wiped out by the reset.

11.10.2015 00:10
I think this is an answer to a rather different question - I interpret the question here to concern the remote repository. by Henke, 08.01.2021 17:35

To keep the changes from the previous commit to HEAD and move to the previous commit, do:

git reset <SHA>

If changes are not required from the previous commit to HEAD and just discard all changes, do:

git reset --hard <SHA>
28.07.2015 08:35

I believe some people may come to this question wanting to know how to rollback committed changes they've made in their master - ie throw everything away and go back to origin/master, in which case, do this:

git reset --hard origin/master

05.02.2015 01:28

Revert is the command to rollback the commits.

git revert <commit1> <commit2> 


git revert 2h3h23233

It is capable of taking range from the HEAD like below. Here 1 says "revert last commit."

git revert HEAD~1..HEAD

and then do git push

20.08.2015 14:45

Idea: You basically want to replace the current working tree state with the one from a previous commit and then create a commit out of it. Ignored files should best be not changed. Here is how:

  1. Emtpy the working tree *.

     git rm -r --cached . && git clean -f -d
  2. Bring the working tree in the state we want **.

     git checkout 0d1d7fc3 .
  3. Create the revert commit.

     git add --all && git commit -m "revert to 0d1d7fc3"

At first I thought that Yarins answer would be the best, but it doesn't work for merge commits. This solution does.

Additionally it does not delete anything (pushed or upushed) from the history. It produces one clean commit which represents the state we want to revert back to.

* by removing untracked but not ignored files (the ones specified in .gitignore) from working tree. The working tree is empty except for the ignored files which we wanted to keep (if not specifiy -x option for clean)

** When a path is specified (here: .), checkout leaves HEAD alone.

10.11.2019 10:10
Thank you so much, this saved my wrecked repo! by Gurpreet Singh Matharoo, 09.10.2020 09:50
Thanks.. dear hands Up for you !!!! by Atif Amin, 02.02.2021 10:52

As your commits are pushed remotely, you need to remove them. Let me assume your branch is develop and it is pushed over origin.

You first need to remove develop from origin:

git push origin :develop (note the colon)

Then you need to get develop to the status you want, let me assume the commit hash is EFGHIJK:

git reset --hard EFGHIJK

Lastly, push develop again:

git push origin develop
20.03.2017 07:33

Try resetting to the desired commit -

git reset <COMMIT_ID>

(to check COMMIT_ID use git log)

This will reset all changed files to un-added state.

Now you can checkout all un-added files by

git checkout .

Check git log to verify your changes.


If you have one and only commit in your repo, try

git update-ref -d HEAD

06.05.2017 23:03

For rollback (or to revert):

1. git revert --no-commit "commit-code-to-remove" HEAD
(e.g. git revert --no-commit d57a39d HEAD)
2. git commit
3. git push

Try the above two steps, and if you find this is what you want then git push.

If you find something wrong, do:

git revert --abort
01.11.2016 14:29

In GitKraken you can do this:

  1. Right click on the commit that you want to reset, choose: Reset to this commit/Hard:

    Enter image description here

  2. Right click on the commit again, choose: Current branch name/Push:

    Enter image description here

  3. Click on the Force Push:

    Enter image description here

Obs.: You need to be careful, because all the commit history after the hard reset are lost and this action is irreversible. You need to be sure what you doing.

02.05.2018 18:41

If you want to correct some error in the last commit a good alternative would be using git commit --amend command. If the last commit is not pointed by any reference, this will do the trick, as it create a commit with the same parent as the last commit. If there is no reference to the last commit, it will simply be discarded and this commit will be the last commit. This is a good way of correcting commits without reverting commits. However it has its own limitations.

01.07.2015 11:35

First, get the string that identifies the commit in some date, doing:

git rev-list -n 1 --before="2009-07-27 13:37" origin/master

It prints the commit identifier, takes the string (for instance XXXX) and does:

git checkout XXXX
05.05.2017 14:39

It can be done much easier with Sourcetree. Just right click commit you are looking for and chose 'Checkout' from menu.

Enter image description here

26.05.2017 11:18

Yet another simplest solution; you have to change branch to do this, but afterwards you can just run:

git branch -f <<branchname>> 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
04.12.2015 15:27
Aw man, why does the OP's question have so many different answers!? Shouldn't stepping back be a simple process? by Kokodoko, 20.03.2016 14:37
Thanks! This method works on bare repo ("git reset" needs working dir, so most of answers here did not work for me). by Egor Skriptunoff, 06.12.2016 08:45

I couldn't revert mine manually for some reason so here is how I ended up doing it.

  1. Checked out the branch I wanted to have, copied it.
  2. Checked out the latest branch.
  3. Copied the contents from the branch I wanted to the latest branch's directory overwriting the changes and committing that.
23.02.2015 17:20
git reflog

Choose the number of the HEAD(s) of git reflog, where you want revert to and do (for this example I choose the 12):

git reset HEAD@{12} --hard
28.09.2016 02:53

The least complicated way I have found to revert a branch to any particular commit, where you can't change the history, is to:

  1. Check out the commit or branch your wish to revert from.
  2. Edit .git/HEAD and change the ref to the branch you which to revert to.

Such as:

echo 'ref: refs/heads/example' > .git/HEAD

If you then do git status, you should see all the changes between the branch you're on and the one you wish to revert to.

If everything looks good, you can commit. You can also use git diff revert..example to ensure that it's the same.

07.12.2017 16:01

If you want to temporarily revert changes because

  • someone committed code that is breaking the build or breaking the functionality you're working on

You can search for the last working commit using git log and then run:

git rebase --onto <commitId>

When the remote branch is working again, you can

git pull --rebase

This method is better than git checkout for temporary changes, because you're not in a detached state.

10.11.2017 20:07

Resetting Staged Changes and Commits

The git reset command lets you change the HEAD- the latest commit your working tree points to - of your repository. It modifies either the staging area or the staging area and working tree.

Git's ability to craft commits exactly like you want means that you sometimes need to undo changes to the changes you staged with git add. You can do that by calling git reset HEAD <file to change>.

You have two options to get rid of changes completely. git checkout HEAD <file(s) or path(s)> is a quick way to undo changes to your staging area and working tree. Be careful with this command, however, because it removes all changes to your working tree.

Git doesn't know about those changes since they've never been committed. There's no way to get those changes back once you run this command.

Another command at your disposal is git reset --hard. It is equally destructive to your working tree - any uncommitted changes or staged changes are lost after running it. Running git reset -hard HEAD does the same thing as git checkout HEAD. It just doesn't require a file or path to work.

You can use --soft with git reset. It resets the repository to the commit you specify and stages all of those changes. Any changes you have already staged are not affected, nor are the changes in your working tree.

Finally, you can use --mixed to reset the working tree without staging any changes. This also unstages any changes that are staged.

Reverting Commits

Sometimes we make mistakes. A commit that wasn't supposed to be shared gets pushed to a public repository, a commit has a bug that can't be fixed and needs to be undone, or maybe you just don't need that code any longer.

These cases all call for git revert. The git revert command does just what you might expect. It reverts a single commit by applying a reverse commit to the history.

Sometimes you need to revert several commits to completely undo a change. You can use -no-commit, or you can use -n to tell Git to perform the revert, but stop short of committing the change.

This lets you combine all the revert commits into one commit, which is useful if you need to revert a feature that spans several commits. Make sure that you revert commits in reverse order-the newest commit first.

Otherwise, you might confuse Git by trying to revert code that doesn't exist yet.

29.01.2019 10:01

There are many answers that provide removing the last commit. However, here is asked how to remove specific commits, and in this case it is to remove the last three commits, to go back to commit on November 3.

You can do this with rebase. Simply do:

git rebase -i HEAD~4

This will list your last four commits.

Now you have the option to remove commits. You do that with drop text.

  • Simply hit i on your keyboard and next to commits you want to remove write drop instead of default pick

  • On the keyboard, hit exit and :wq

To make sure that commits are removed, write:

git log

You will see that commits you saved as drop are removed.

To push those changes to your remote branch, write:

git push --force
07.01.2020 00:35