I once ran git reset without thinking and watched hours of work vanish.
The command is powerful. It can rewrite history, move branches, and change the state of your working directory in ways that are invisible until too late. The git reset manpages are the only complete map if you want to use it without fear. They are dense, but they tell you exactly how git reset works and why it behaves the way it does.
git reset changes the current branch’s HEAD to the specified state. The manpage breaks it into three forms:
1. git reset --soft <commit>
Moves HEAD to the given commit, keeps your index and working tree. Staged changes remain staged.
2. git reset --mixed <commit> (default)
Moves HEAD, resets the index, but leaves your working tree alone. Changes become unstaged.
3. git reset --hard <commit>
Moves HEAD, resets both index and working tree. All uncommitted changes are lost.
The manpages also explain special commit references like HEAD~1, branch names, and hashes. They cover --merge and --keep modes, which try to protect changes during a reset. They warn about the dangers of rewriting history when a branch is shared. The document makes it clear: this is less about undoing and more about precise control of pointers and trees.
Beyond modes, the manpages clarify the difference between git reset and git checkout or git restore. reset is about setting HEAD and optionally updating index and working tree. It is not a file-level operation, though you can pass paths to limit scope. This is where most new users trip up.
One of the key insights is that git reset operates in layers: HEAD, index, working directory. The manpages show how flags choose which layers are updated. Understanding these layers is the difference between a surgical correction and a disaster.
Before running git reset, decide on the exact commit target and choose the mode carefully. Read the manpage examples twice. Test on a disposable branch if the history is shared.
If you want to see these principles work in a live project without wasting time on environment setup, run it on an ephemeral service like hoop.dev. You can be inside a real repo in minutes, test resets safely, and see their effects on HEAD, index, and working tree in real time.
Master git reset by studying the manpages, then put that knowledge into practice where mistakes won’t cost you. Precision comes from use, not theory. The less you guess, the more control you have.