GIT FIELD GUIDE // 04
Recover Git history without destroying useful work
Choose revert for published history and use the reflog to anchor commits that disappeared after a local rewrite.
A change went wrong. Inspect the evidence and restore the repository without losing useful work.
BEFORE YOU START
Prerequisites and boundaries
- Stop making new history changes until the target commit is identified.
- Record the current branch and working-tree state before attempting recovery.
- Distinguish a published commit from a local-only commit before choosing revert or reset.
OPERATIONAL REASONING
Why this sequence matters
The goal is not merely to memorize commands. Each inspection, change, and verification step reduces a different failure mode.
Inspect the target object
A commit hash is not enough; review its parents and patch before reversing or recovering it.
Preserve shared history
Revert adds a compensating commit and avoids changing commit identifiers already used by others.
Anchor a lost commit
Creating a branch at the reflog entry makes the recovered object reachable before further cleanup.
STANDARD PROCEDURE
Undo a bad shared commit without rewriting the published branch.
Inspect the repository and target commit before creating a new revert commit, then confirm the working tree is clean.
- 01
git statusGit status documentation ↗ - 02
git log --onelineGit log documentation ↗ - 03
git show abc1234Git show documentation ↗ - 04
git revert abc1234Git revert documentation ↗ - 05
git show --stat HEADGit show documentation ↗
INCIDENT RESPONSE
Recover a commit that disappeared after an accidental history rewrite.
Use the reflog to locate the lost object, inspect it, anchor it with a branch, switch to that branch, and verify the recovered history.
- 01
git reflogGit reflog documentation ↗ - 02
git show abc1234Git show documentation ↗ - 03
git branch recovery abc1234Git branch documentation ↗ - 04
git switch recoveryGit switch documentation ↗ - 05
git log --onelineGit log documentation ↗
COMMON FAILURE MODES
What usually goes wrong
- reset --hard was used on a dirty working tree and discarded unrelated changes.
- The wrong commit was reverted because its patch and parent relationship were not inspected.
- A reflog entry expired before the lost commit was anchored with a branch or tag.
VERIFICATION
Evidence to collect
- git show displays the exact commit selected for recovery or reversal.
- git log --oneline --decorate shows the new recovery branch or revert commit.
- git status confirms that no unreviewed changes remain in the working tree.