You don't lose a commit just because you use git reset --hard. The author either doesn't know how git branches work and/or how to use reflog, or he means to say he lost the uncommitted content of his working tree.
You don't lose a commit just because you use git reset --hard. The author either doesn't know how git branches work and/or how to use reflog, or he means to say he lost the uncommitted content of his working tree.
These days there's little reason to do reset --hard. `git reset --merge` is much safer and can be used almost anytime you would have otherwise done `--hard`.
e.g. if you want to force your branch to point at "foo", you can `git reset --merge foo` and it'll bail out if it detects that you have uncommitted edits that would have been lost by moving to "foo". If it can safely move the uncommitted edits there, it'll do it.
When you do this by mistake and you don't know the hash you can find it using git reflog, which logs everything that happens in the repository.
More detailed: http://gitready.com/intermediate/2009/02/09/reflog-your-safe...
git reflog
Might be your saviour here next time.