What's the difference between reset, revert and restore?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
reset moves a branch pointer, optionally changing working tree (--soft keeps changes staged, --mixed unstages, --hard discards) — rewrites local history. revert creates a new commit undoing an old one — safe for shared branches. restore discards/unstages working-tree changes without touching history.
Detailed explanation
Three tools for three situations. reset rewinds your branch to a chosen commit: --soft leaves changes staged (redo commits differently), --mixed (default) unstages them, --hard deletes the changes outright — powerful locally, dangerous pushed, because it erases commits others may have. revert computes the inverse patch of a target commit and commits it — history stays intact, everyone sees the undo explicitly; the only safe way to cancel merged work (also how you revert a revert). restore (newer, friendlier) handles uncommitted messes: restore file.js discards edits, restore --staged file.js unstages without losing work — replacing awkward checkout syntax. Recovery safety net: reflog records where HEAD moved, so even hard resets are recoverable for ~90 days. Decision heuristic: uncommitted? restore. Committed locally? reset. Already public? revert.
Example
# Uncommitted changes:
git restore app.js # discard file edits
git restore --staged app.js # unstage only
# Local-only commits:
git reset --soft HEAD~1 # undo last commit, keep staged
# Public branch — safe undo:
git revert abc1234 # new inverse commitInterview tip
Organize by commit-state: working tree → restore, local commits → reset, pushed commits → revert. Mentioning reflog rescue earns bonus depth.
Common mistakes
- Using reset --hard on shared branches.
- Not knowing --soft vs --mixed staging outcomes.