Undoing Changes, Reset, Restore, Revert, Reflog, and Lost-Work Recovery: Concepts, Architecture, and Mental Model

1. Recovery starts by naming the layer that is wrong

Chapters 04 and 09 established the layers that Git can change: the working tree, the index, refs such as the current branch, commit history, and remote/shared history. “Undo my mistake” is therefore incomplete. A safe recovery question is: which layer contains the mistake, which layer still contains the version I want, and has the mistaken state already been published?

If a file is wrong only in the working tree, moving a branch ref is unnecessary. If one path is staged accidentally, destroying the working tree is unnecessary. If a bad commit was already shared, rewriting the branch may be worse than the original bug. This chapter turns those distinctions into a repeatable incident-response decision process.

2. Preserve evidence before mutating anything

git rev-parse --show-toplevel
git status --short --branch
git diff
git diff --staged
git log --graph --decorate --oneline --all --max-count=20
git reflog -10
git show --stat --summary HEAD
git branch -vv

This establishes location, dirty state, staged state, graph shape, recent ref movement, current commit contents, and publication/tracking clues. Capture output or exact OIDs during a real incident before running commands that move refs or overwrite files.

3. Four different “undo” problems

The table is a starting point, not permission to run a command blindly. Always inspect path scope, target commit, and publication state.

4. Restore copies content into a selected destination layer

With no --staged, git restore path restores the working tree from the index by default. With --staged, the destination is the index and the default source is HEAD. An explicit --source=<tree> changes the source.

git diff -- app.conf
git restore -- app.conf

git diff --staged -- app.conf
git restore --staged -- app.conf

git restore --source=HEAD~1 -- app.conf

5. Reset moves HEAD and optionally synchronizes lower layers

When used with a commit target, reset moves the current branch/HEAD to that commit. The mode controls what else follows the new HEAD.

6. Reset mode state map

flowchart TD
T[Target commit/tree]
S[--soft]
M[--mixed]
H[--hard]
HEAD[HEAD/current branch]
IDX[Index]
WT[Working tree]
T --> S --> HEAD
T --> M --> HEAD
M --> IDX
T --> H --> HEAD
H --> IDX
H --> WT

The diagram shows destination scope. Soft moves only the ref. Mixed moves the ref and makes the index match the target, while preserving working-tree files. Hard moves all three layers to the target. It does not depict remote history; reset is fundamentally a local ref/state operation until you publish a replacement ref.

7. Revert preserves history by adding a new inverse commit

git revert BAD computes the change needed to reverse the effect of BAD and records that reversal as a new commit. The old bad commit remains in history. That makes revert appropriate for many shared-history corrections: the event and its correction are both auditable.

git show --stat BAD
git revert BAD
git log --oneline -4

Revert can conflict if later history changed the same content. It also has special semantics for merge commits because Git must know which parent represents the mainline; Lesson 4 treats that explicitly.

8. Reflog is a local journal of ref movement

A reflog records recent values of refs in one repository. Entries such as HEAD@{1} or an exact OID can reveal where a branch/HEAD pointed before reset, rebase, amend, checkout/switch, or commit operations.

git reflog --date=local
git show HEAD@{1}
git branch recovered-work <verified-old-oid>

Reflogs are local. Another clone/server may have different history and different retention. Current defaults normally expire reachable reflog entries after about 90 days and entries unreachable from the current tip after about 30 days, unless configuration changes those windows.

9. Reachable, unreachable, and dangling are object-graph terms

A commit is reachable when Git can walk to it from a root such as a branch/tag/ref. An object can become unreachable when no ref reaches it—for example after a reset or branch deletion. git fsck can report unreachable or dangling objects that still physically exist. “Dangling” is a diagnostic notion for an object present in the database but not directly used by another object in the traversed graph.

Existence is not permanence. Reflog expiry and garbage collection can eventually remove protection and prune old unreachable objects. Recovery should happen before maintenance, not after aggressive cleanup.

10. DevOps incident-response connection

A production rollback discussion often begins with “what changed?” Git recovery adds two further questions: “which exact OID/ref represented the known-good state?” and “should we preserve the bad event in shared history?” Additive reverts are often operationally preferable on published branches because deployment records, reviews, attestations, and incident timelines keep referring to stable commit IDs.

11. Knowledge check

12. Summary

Recovery is a state-selection problem. Restore targets path content in the working tree/index; reset moves a local ref and optionally synchronizes index/working tree; revert adds an auditable correction to history; reflog helps locate prior local ref values. The safest recovery command is the narrowest one that changes the layer actually at fault.

Authoritative references

• git-restore
• git-reset
• git-revert
• git-reflog
• git-fsck