reset vs revert: Which One, When
Rewriting History vs Adding an Inverse Commit
Both 'undo' things, but in very different ways.
reset
Moves the branch pointer to a specified commit. Commits after that point disappear from history (though the objects linger in reflog).
--soft: moves HEAD only. Changes stay staged--mixed(default): moves HEAD + resets index. Changes stay in working tree--hard: moves HEAD + index + working tree. Hard to recover
revert
Creates a new commit that applies the inverse of the target commit. History stays intact; an 'undo commit' is appended to the end.
Which to pick
Not pushed yet? reset is cleanest.
Already pushed? Use revert. Resetting and force-pushing breaks everyone else's history.
Recovering from mistakes
Even after git reset --hard, don't panic. git reflog keeps a record of recent HEAD moves. Reset back to the hash you wanted. Default retention is 30 days.
How It Works
`git reset --soft HEAD~1` -> undo last commit, keep changes staged
`git reset --hard <hash>` -> full reset to specified commit (dangerous)
`git revert <hash>` -> creates a new commit that undoes the target
`git reflog` -> view HEAD move history, used to recover from mistakes
Pros
- ✓ reset: history disappears cleanly
- ✓ revert: safe, does not break shared history
Cons
- ✗ reset: dangerous on shared branches
- ✗ revert: leaves an undo commit in history