1
  1. I committed my changes, and started working on a new feature.
  2. I realized that I have messed things up
  3. Needed to revert back to the previous commit.

What I did.

git add .
git commit -m "Screwed Up"
git branch -m experiment
git checkout 62b5 (SHA1 of previous commit)
git checkout -b master
git branch -D experiment

I think there must be a better way to revert to the previous commit.

When I tried, git reset HEAD, it would still show the uncommitted changes, when I do git status.

If there's a better way to do it, what is it ? Or should I be using a different workflow to avoid situations like this ?

yasith
  • 8,981
  • 7
  • 27
  • 32
  • possible duplicate of [GIT revert to previous commit... how?](http://stackoverflow.com/questions/4114095/git-revert-to-previous-commit-how) – jamessan Dec 23 '12 at 21:43
  • 1
    Also see [Undo last Git commit](http://stackoverflow.com/questions/927358/undo-last-git-commit). Read the answer by Kyralessa, it's more complete than the accepted answer. – herzbube Dec 23 '12 at 21:48

2 Answers2

3

You can do git reset --hard to revert back to the previous commit.

--hard will reset the index and working tree. Any changes to tracked files in the working tree since the latest commit will be discarded.

Faruk Sahin
  • 8,406
  • 5
  • 28
  • 34
  • If I have un-tracked files, do I have to add them, before resetting ? – yasith Dec 23 '12 at 21:45
  • Git will not touch to untracked files. If you have made changes in the untracked files, git won't be able to revert them since there is no information stored for that file in git repo. – Faruk Sahin Dec 23 '12 at 21:48
  • Please read my answer before blindly using reset hard on a day to day basis. – Adam Dymitruk Dec 23 '12 at 22:07
  • The changes are *not* gone for good (if you still know the sha of the commit(s) you "undid"); `reset` only moves the branch pointer, it does not change commits. If you have another branch which includes them, or if you create such a branch later on, you can still re-use them. Maybe you should edit your answer to clear that up :) – Nevik Rehnel Dec 23 '12 at 22:27
  • Thanks @NevikRehnel for clarification :) But, in this case I assumed nothing was committed. – Faruk Sahin Dec 23 '12 at 22:35
  • That is the problem with reset hard. There are no old commits to recover from reflog. The changes are _gone_! `reset --mixed`, `reset --soft` just move the commit pointer. However, `reset --hard` also affects the work tree. This is why you have to be careful and I don't recommend using it. – Adam Dymitruk Dec 23 '12 at 23:12
  • @AdamDymitruk: That depends on whether the changes have been committed yet. I generally assume that everything is always committed before doing anything, in which case my answer is correct, you don't lose anything. It's true, of course, that uncommitted changes will be discarded. – Nevik Rehnel Dec 24 '12 at 08:37
  • That's the issue. If you don't bother to run `git status` first, `git reset --hard HEAD^` will not warn you that you are doing a potentially irreversible operation. I now do `git reset HEAD^` and `git stash -u` just in case. Usually though, `git reset --hard` is a way that people clean the work tree. `git stash -u` is better for that if you clean the work tree by mistake. – Adam Dymitruk Dec 24 '12 at 18:08
1

Do not reset --hard if possible. It's undoable if you have untracked or unstaged changes. Use

git stash -u

to be safe. You will get a clean work directory again. If you threw away your changes by mistake, you can always get them back via git stash commands.

Stashed changes don't get pushed up so it won't mess up anything on/bloat other repos but give you a bit of a safety net. So if you reclone, you will lose your stashes. So recloning to fix issues with your repo is also a bad idea - you can also lose your rerere recordings, reflog, etc.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141