How to revert a Git repository to a previous commit

6 331

2 946

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 <[email protected]>
Date:   Thu Nov 4 18:59:41 2010 -0400

blah blah blah...

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

more blah blah blah...

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

And yet more blah blah...

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

Yep, more blah blah.

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

Crazy Serb

Posted 2010-11-06T16:58:14.550

Reputation: 31 124


Related How to undo the last Git commit?.

– None – 2014-05-23T17:57:12.580


Here's a very clear and thorough post about undoing things in git, straight from Github.

– Nobita – 2015-06-08T19:41:52.087


Related: Rollback to an old Git commit in a public repo. Note that that question adds a constraint that the repo is public.

– None – 2015-10-19T09:51:42.507

13I 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? – The Muffin Man – 2018-01-03T22:26:59.923


8 173

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:
git revert a867b4af..0766c053 

# 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 to move HEAD back to a previous location? (Detached head)


Posted 2010-11-06T16:58:14.550

Reputation: 324 927

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. – trusktr – 2012-03-18T21:55:46.430

1Just one thing... how do I come back to head? After doing git checkout 0d1d7fc32?? – Jaime Hablutzel – 2012-04-14T03:15:15.113

1@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 &lt;branch&gt; would be the explicit way. (As with anything about Git here, please be careful running commands if you don't understand what they do.) – Cascabel – 2012-04-14T06:25:38.610

1By head I was talking about the commit I was before, the last one – Jaime Hablutzel – 2012-04-14T08:02:16.723

You probably had a branch checked out, not just a commit - and you should probably understand the difference before you deliberately detach HEAD again. – Cascabel – 2012-04-14T13:59:23.603

82@Rod's comment on git revert HEAD~3 as the best wat to revert back 3 commits is am important convention. – New Alexandria – 2012-08-22T15:16:45.317

12Could you write the whole number? like: git reset --hard 0d1d7fc32e5a947fbd92ee598033d85bfc445a50 – Spoeken – 2012-12-04T13:58:13.573


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

– Cascabel – 2012-12-04T16:55:52.413

2I 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 – Xavier John – 2013-01-17T19:08:02.497

209To get back to current the command is 'git checkout master' – Xavier John – 2013-01-18T00:33:26.117

46You can use git revert --no-commit hash1 hash2 ... and after this just commit every single revert in one commit git commit -m "Message" – Mirko Akov – 2013-09-24T12:12:16.757

YOu need to do a git push origin master after revert. – chovy – 2013-11-16T06:54:03.417

Git community book link is dead. Is this a good replacement?

– James Kingsbery – 2013-12-17T21:30:40.227

1Don't miss the RANGE ( as in git revert HEAD~2..HEAD. Happens... – raoulsson – 2014-01-03T12:15:06.477

Why use git stash &amp;&amp; git reset --hard &amp;&amp; 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. – gregers – 2014-01-14T12:49:51.360

@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). – Cascabel – 2014-01-14T17:27:19.847

@JamesKingsbery It doesn't mention "git revert". – dentarg – 2014-02-10T18:49:47.780

1Shouldn't git checkout -b old-state 0d1d7fc32 be git checkout 0d1d7fc32 -b old-state instead? – Yarin – 2014-02-12T00:56:20.300

@Yarin No. From the usage statements at the top of the man page, paraphrased: git checkout [-b &lt;new_branch&gt;] [&lt;start_point&gt;]. What you wrote might work too, but it's not the normal order of options and arguments, and it's not documented as working. – Cascabel – 2014-02-12T01:27:26.187

1BTW, 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. – nahtnam – 2014-04-26T21:52:24.553

2What does 'publish' mean in this context? – Howiecamp – 2014-08-20T22:06:31.510

1@Yarin's answer is safer. Please take a look before you decide what to do. – Dr Beco – 2014-11-23T05:31:27.363

@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. – Cascabel – 2014-11-23T06:21:29.037

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. – Dr Beco – 2014-11-23T18:55:35.273

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 – Sainath S.R – 2014-12-27T18:24:16.607

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 – schmidlop – 2015-02-21T17:58:21.780

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 – mannuk – 2015-03-06T13:47:39.320

so, can anyone tell me how to go back to the latest commit after doing "git checkout 0d1d7fc32" ?? – tyegah123 – 2015-03-10T10:56:44.883

@tyegah123 @mannuk type git checkout master – Jody Lee Bruchon – 2015-05-11T02:27:49.083

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. – Loax – 2015-05-13T15:16:46.317

Temporarily switch to a different commit - how to switch back? – アレックス – 2015-06-28T09:31:29.817

@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. – Cascabel – 2015-07-08T22:10:52.070

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'" – Don Hatch – 2015-07-09T11:44:56.210

Note Don't forget to "unprotect" your branch in question when using hard resets on gitlab or github. – ferdy – 2015-09-16T07:32:54.023

@Jefromi, after "git checkout 0d1d7fc32 .", is the HEAD already detached? Then "git commit" cannot do anything with the dangled HEAD. – user1914692 – 2015-11-11T17:03:16.763

@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. – Cascabel – 2015-11-11T17:57:49.327

@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>…​" ? – user1914692 – 2015-11-12T17:10:04.107

@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." – Cascabel – 2015-11-12T17:41:05.680

@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"

– user1914692 – 2015-11-12T21:42:54.857

@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 &lt;branch&gt; &lt;path&gt;, it does not switch to that branch, and if you do git checkout &lt;commit&gt; &lt;path&gt; it does not detach HEAD by switching to that commit. – Cascabel – 2015-11-12T22:37:24.080

@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. – Cascabel – 2015-11-12T22:38:50.253

@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." – user1914692 – 2015-11-12T22:55:12.190

Let us continue this discussion in chat.

– Cascabel – 2015-11-13T00:33:39.103

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? – 7stud – 2016-01-28T05:12:28.760

@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. – Cascabel – 2016-01-28T05:40:01.077

@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? – 7stud – 2016-01-28T06:07:24.853

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.) – Cascabel – 2016-01-28T06:11:19.957

@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? – 7stud – 2016-01-28T06:16:01.757

Let us continue this discussion in chat.

– Cascabel – 2016-01-28T06:22:45.497

@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. – user137717 – 2016-04-28T16:15:19.113

i just use git reset --hard 0d1d7fc32 – raditya gumay – 2016-07-13T02:32:46.777

git push -f origin master to fix remote after you've fixed local. – John Erck – 2016-08-22T19:02:29.857

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. – Daniel Dewhurst – 2016-11-03T12:22:37.990

@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? – Alex Ventura – 2016-11-23T05:57:26.073

@AlexVentura There's a section called "hard delete unpublished commits". – Cascabel – 2016-11-23T06:59:49.747

@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. – Alex Ventura – 2016-11-23T19:32:44.837

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

– Cascabel – 2016-11-23T19:44:06.323

@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? – Alex Ventura – 2016-11-23T19:56:00.440

1@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. – Cascabel – 2016-11-23T20:31:54.347

3 sections and none of them useful. The real answer is below: git revert --no-commit 0766c053..HEAD – user3690202 – 2017-01-01T02:29:48.913

1git 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. – Sebastian – 2017-01-19T12:30:38.463

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. – Jordan Stefanelli – 2017-08-15T10:48:20.733

@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. – Cascabel – 2017-08-15T15:09:41.557

The commit range was especially helpful. Thanks! – Chip Castle – 2018-03-15T14:53:33.963

So what if I only want to revert the last published commit - can I do it by git revert HEAD ? – Adam – 2018-08-27T16:03:37.457

1 344

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 [email protected]{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?.


Posted 2010-11-06T16:58:14.550

Reputation: 26 043

25I 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... – Lennon – 2012-09-24T18:17:28.717

5It 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) – vinothkr – 2012-12-05T04:51:51.950

11Obligatory Warning: don't hard reset 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. The soft reset is safe though, as well as the last solutions in this answer. – None – 2014-06-28T20:06:00.297

4I 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 [email protected]{1}; git commit. – None – 2014-06-29T00:20:29.117

3If you're working in PowerShell, add quotes around [email protected]{1}:

git reset --soft '[email protected]{1}'

because curly braces have a meaning – Amadeusz Wieczorek – 2014-08-25T23:06:35.020

2Shame a versioning system makes the syntax so complicated for basic history-browsing acitons. – user776686 – 2015-03-17T11:57:18.923

4@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 – boulder_ruby – 2015-05-18T23:56:00.347

1It makes me use vim and I don't know how... so frustrating. – pixelfairy – 2015-11-28T18:29:14.023

1@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' – boulder_ruby – 2016-02-09T16:40:11.013

Why not just: git reset --hard "(older commit)"? – Goldname – 2016-08-07T18:45:21.847

1@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! – Brian Knoblauch – 2016-09-28T19:38:59.620

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. – user3690202 – 2017-01-01T02:26:29.857

2@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. – Suncat2000 – 2018-02-21T16:03:43.850

Thanks a lot @boulder_ruby! – Alexandros – 2018-11-06T12:14:44.693

1 311

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


Posted 2010-11-06T16:58:14.550

Reputation: 70 349

15If 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. – None – 2014-06-28T20:11:40.217


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:

– timhc22 – 2014-11-21T11:55:43.127

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? – mike rodent – 2015-05-13T08:17:15.633

3To see the diffs before you commit use git diff --cached. – John Erck – 2015-11-06T18:35:20.673

3This 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 – Alex Punnen – 2016-02-22T09:06:02.403

I just checked out the commit hash and created a new branch from there to work; This is more safe and easier – Alex Punnen – 2016-03-24T08:59:43.290

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. – Celeritas – 2016-05-22T23:12:35.533

14$ git revert --no-commit 53742ae..HEAD returns fatal: empty commit set passed – Alex G – 2016-08-01T20:30:18.953

This is best answer of this question, it help me to create a commit after full revert back my code to a different tree. – Subho – 2016-08-12T07:14:07.450

1Indeed, @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... :-) – Brian Knoblauch – 2016-09-28T19:43:35.480

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 – maQ – 2016-11-10T11:59:32.123

9@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 – EpicPandaForce – 2017-04-16T14:22:51.077

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. – Cookie – 2018-01-22T16:24:21.850

1@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. – Yarin – 2018-01-22T21:05:38.417

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. – Cookie – 2018-01-22T21:11:06.790

"is a merge but no -m option was given." – Philip Rego – 2018-02-06T20:36:28.740

In my opinion, the better approach to git revert --no-commit is git diff &lt;commit-you-want-to-revert-to&gt; &gt; my-diff; patch -R -t -p1 &lt; my-diff. This approach doesn't have the problem about -m option was given, and no history is destroyed either. – Sorawee Porncharoenwase – 2018-04-07T18:30:10.340

1This yields an error: error: commit d85f9b88d is a merge but no -m option was given. fatal: revert failed – Igor Ganapolsky – 2018-08-22T15:13:28.817

Thank you for not being a mindless idiot and instead publishing a USEFUL reply that works for the majority of scenarios. – Florian Heigl – 2018-11-12T02:30:47.747


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


Posted 2010-11-06T16:58:14.550

Reputation: 4 987

28Obligatory 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. – None – 2014-06-28T20:03:54.000

5I 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. – ashnazg – 2014-10-29T14:46:25.160

1remember, clean will remove files/folders such as .idea (phpstorm) or .vagrant (vagrant) which may be used by your set up/IDE! – timhc22 – 2014-11-21T11:59:11.677

3git clean -f

DANGER DANGER – Tisch – 2015-07-16T14:59:20.513

1@Pogrindis - plenty of good answers on here that don't delete untracked files. – Tisch – 2015-07-17T10:29:14.637

1If you use "git clean -f" I recommend checking first what you'll delete with: git clean -f -n – andreyro – 2016-12-08T14:13:50.160

2This 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? – Ade – 2017-10-22T11:47:32.877

1@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.. . – Pogrindis – 2017-10-23T09:02:57.080

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. – Siddharth – 2018-06-09T07:04:32.463


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 [email protected]{...}

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


Posted 2010-11-06T16:58:14.550

Reputation: 49 194

4Excellent hint to git reflog, that's exactly what I needed – smac89 – 2016-03-13T21:25:01.697

1Ouch! 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.... – Kokodoko – 2016-03-20T14:35:15.773

there is: git reset HEAD^ --hard` – CodeWizard – 2016-03-20T14:38:43.403

2@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. – mike rodent – 2016-08-29T17:17:51.107


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.


Stephen Ostermiller

Posted 2010-11-06T16:58:14.550

Reputation: 13 526

3This is soft and gently: risk free if you haven't pushed your work – nilsM – 2017-01-18T10:04:18.380


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.

Roman Minenok

Posted 2010-11-06T16:58:14.550

Reputation: 7 268


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.

kiran boghra

Posted 2010-11-06T16:58:14.550

Reputation: 2 122

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! – Gene Bo – 2016-09-16T19:47:15.543

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 – Gene Bo – 2016-09-16T19:49:36.657

This was the only way for me to undo a bad merge, revert didn't work in that case. Thanks! – Dave Cole – 2017-01-19T20:07:19.923


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.

Lance Caraccioli

Posted 2010-11-06T16:58:14.550

Reputation: 1 115

40You could do a git revert HEAD~3 to remove the last 3 commits – Rod – 2012-02-19T18:59:22.010

21@Rod - No, that's not right. That command will revert the commit that is the third grandparent of HEAD (not the last three commits). – kflorence – 2012-09-11T22:13:05.687


@kflorence Ok thanks for the info. Would git revert -n master~3..master~1 work ? (As seen from

– Rod – 2012-09-12T01:59:58.160

3@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. – kflorence – 2012-10-01T01:12:03.380

1@kflorence doesn't that require you to make a new branch though? – Mike Vella – 2013-08-20T11:29:41.670

1@Lance I agree with you about git revert --to - this seems like an unbelievably complex way to achieve quite a simple thing! – Mike Vella – 2013-08-20T11:31:21.380

@MikeVella Nope, no need to create a new branch. – kflorence – 2013-08-21T00:21:25.170

5There's a much easier way to do this now than with a script like this, just use git revert --no-commit &lt;start&gt;..&lt;end&gt;, 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. – None – 2014-06-28T20:02:39.933


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


Posted 2010-11-06T16:58:14.550


About Alternative 1, one quick question: By doing so we don't loose in between commits right? – Bogac – 2014-12-02T10:14:33.157

in Alternative 2, dots stand for what in those commands? – Bogac – 2014-12-02T10:21:40.910

2@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. – Tom – 2014-12-02T19:06:38.037


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 :)

Paul Walczewski

Posted 2010-11-06T16:58:14.550

Reputation: 625


Nothing here worked for me apart from this exact combination:

git reset --hard <commit_hash>
git push origin <branch_name> --force

Key here is forcing the push, no extra commits/commit messages etc.


Posted 2010-11-06T16:58:14.550

Reputation: 1 043


OK, going back to 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>

Explain: 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 flags:


The default flag as explained, not need to provide it, does not change the working tree, but add all changes 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 happens in a real life working with git:

git reset to a commit


Posted 2010-11-06T16:58:14.550

Reputation: 43 514


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

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

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

I found the answer from in blog post Delete remote Git repo to specific commit.


Posted 2010-11-06T16:58:14.550

Reputation: 542


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

git push -f ...

And not only git push.


Posted 2010-11-06T16:58:14.550

Reputation: 6 318

11Obligatory 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. – None – 2014-06-28T20:00:19.813

3Sometimes 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. – Doug R – 2014-10-22T20:44:19.463

Thanks! I couldn't figure out how to get the remote branch to match my local branch, Just needed to do a force push. – Mido – 2017-02-06T12:49:58.777


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

Shadow Man

Posted 2010-11-06T16:58:14.550

Reputation: 1 993


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.


Posted 2010-11-06T16:58:14.550

Reputation: 410

7Obligatory 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. – None – 2014-06-28T19:57:00.310

1Also, to be clear, git show HEAD is equivalent to just using git log HEAD -1. – None – 2014-06-28T19:58:54.367


Revert to most recent commit and ignoring all local changes:

git reset --hard HEAD

Mohammed Irfan Tirupattur

Posted 2010-11-06T16:58:14.550

Reputation: 959


You can complete all these initial steps yourself and push back to git repo.

  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 repo using git push --force to force push the change.

If you want git repository to a previous commit

git pull --all
git reset --hard HEAD~1
git push --force

Nanhe Kumar

Posted 2010-11-06T16:58:14.550

Reputation: 8 816


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>

Vishnu Atrai

Posted 2010-11-06T16:58:14.550

Reputation: 1 804


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.

Chris Moschini

Posted 2010-11-06T16:58:14.550

Reputation: 25 569


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.

Point Networks

Posted 2010-11-06T16:58:14.550

Reputation: 438


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


Posted 2010-11-06T16:58:14.550

Reputation: 4 455


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

Sireesh Yarlagadda

Posted 2010-11-06T16:58:14.550

Reputation: 7 213


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 directory "my project":

  1. Copy the whole directory and call it something else, like "my project - copy"

  2. Do:

    git reset --hard [first-4-letters&numbers-of-commit's-SHA]

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 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 probably do another commit fairly soon.

Git is a brilliant creation but you can't 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 you have to pretty much have to read a book on Git - I'd recommend "Version Control with Git". And if you can trust me (or rather my scars) when I say "have to", it follows that you might as well do it NOW. Much of the complexity of Git comes from branching and then remerging. But 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 repository ("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.

mike rodent

Posted 2010-11-06T16:58:14.550

Reputation: 3 625


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


Posted 2010-11-06T16:58:14.550

Reputation: 474


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

George Ninan

Posted 2010-11-06T16:58:14.550

Reputation: 689


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.

Upul Doluweera

Posted 2010-11-06T16:58:14.550

Reputation: 723


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 similar issue and wanted to revert back to earlier Commit. In my case I was not intetessered to keep newer commit hence I used Hard.

This is how I did it:

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

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

git push -f


Posted 2010-11-06T16:58:14.550

Reputation: 10 020


On 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

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

enter image description here

  1. Click on the Force Push:

enter image description here

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

Ângelo Polotto

Posted 2010-11-06T16:58:14.550

Reputation: 427


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 above two steps, and if you find this is what you want then git push.

If you find something wrong do:

git revert --abort

Jagraj Singh

Posted 2010-11-06T16:58:14.550

Reputation: 226


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

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

it prints the commit identifier, take the string (for instance XXXX) and do:

git checkout XXXX

Luca C.

Posted 2010-11-06T16:58:14.550

Reputation: 3 170


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

git branch -f <<branchname>> 0d1d7fc32e5a947fbd92ee598033d85bfc445a50


Posted 2010-11-06T16:58:14.550

Reputation: 9 022


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

Marcin Szymczak

Posted 2010-11-06T16:58:14.550

Reputation: 6 673


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.


Posted 2010-11-06T16:58:14.550

Reputation: 3 268


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 [email protected]{12} --hard


Posted 2010-11-06T16:58:14.550

Reputation: 4 517


Revert Most Recent Commit :

git reset --hard 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.

Revert to an Older Commit : The fastest way to restore an old version is to use the reset command:

# Resets index to former commit
git reset 56e05fced 

# Moves pointer back to previous HEAD
git reset --soft [email protected]{1}

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

This will rewind your HEAD branch to the specified version. All commits that came after this version are effectively undone; your project is exactly as it was at that point in time.

The reset command comes with a couple of options, one of the more interesting ones being the --soft flag. If you use it instead of --hard, Git will keep all the changes in those "undone" commits as local modifications.

Restoring a Revision in a New Local Branch

As said, using the reset command on your HEAD branch is a quite drastic action: it will remove any commits (on this branch) that came after the specified revision. If you're sure that this is what you want, everything is fine.

However, there is also a safer way in case you'd prefer leaving your current HEAD branch untouched. Since "branches" are so cheap and easy in Git, we can easily create a new branch which starts at that old revision:

git checkout -b old-project-state 0ad5a7a6

Normally, the checkout command is used to just switch branches. However, providing the -b parameter, you can also let it create a new branch (named old-project-state in this example). If you don't want it to start at the current HEAD revision, you also need to provide a commit hash - the old project revision we want to restore.

You now have a new branch named old-project-state reflecting the old version of your project - without touching or even removing any other commits or branches.


Posted 2010-11-06T16:58:14.550

Reputation: 1 832


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

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


Posted 2010-11-06T16:58:14.550

Reputation: 1 418


If you want to temporarily revert changes because

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

You can search for the last working commit using git log 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.


Posted 2010-11-06T16:58:14.550

Reputation: 580