Undoing changes — restore, reset, and revert

Every "undo" scenario in Git maps to one of these three tools, and the deciding factor is always the same: how far has this change traveled. Using the wrong one is the actual source of most real Git accidents — not the individual commands themselves, which are each safe when used for what they're meant for.

git restore (the modern replacement for older, more overloaded uses of git checkout) operates entirely before a commit exists — git restore given a filename throws away uncommitted edits to that file, reverting it to match the last commit; git restore --staged given a filename un-stages it without touching its actual content, moving it back from the staging area to the working directory. Neither of these touches commit history at all, since nothing has been committed yet — this is the safest category of undo, reversible right up until it's run (the discarded edits themselves are genuinely gone once restore runs without --staged, so it's worth a git diff check first).

git reset moves the current branch's pointer backward (from the branching lesson's "a branch is just a pointer" model) — effectively un-committing one or more commits. The three modes differ in what happens to the changes those commits contained: --soft keeps them staged, ready to re-commit differently; --mixed (the default) keeps them in the working directory, unstaged; --hard discards them completely, with no recovery through ordinary means. reset is genuinely safe only on commits that haven't been pushed anywhere — rewriting history that only exists locally doesn't affect anyone else, since nobody else has that history yet.

If a commit has already been pushed and someone else might have already pulled it (or built more commits on top of it), reset rewrites history that other people's local copies still expect to exist — pushing afterward requires --force, which can silently erase commits a teammate is actively relying on. This is exactly why reset is scoped to local, unshared commits: rewriting history is fine when only one copy of it exists; it becomes destructive the moment other copies have already diverged from it.

git revert, given a commit hash, doesn't remove the target commit or rewrite history at all — it creates a new commit that applies the exact opposite of the target commit's changes. This is the safe way to undo something that's already been pushed and shared: the original commit (B above) stays in history exactly as it was, and a new commit (D) sits on top, undoing its effect — everyone else's copy of history stays valid, since nothing already-shared was removed or rewritten, only added to.

This is the entire decision, and it maps directly onto the "how far has this change traveled" question from the top of this lesson. Reaching for reset --hard on a commit that's already been pushed and pulled by someone else is the single most common way Git accidents actually happen — not because reset is inherently dangerous, but because it's being used on history that isn't safely local anymore.