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.

Scenario

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.

01

Inspect the target object

A commit hash is not enough; review its parents and patch before reversing or recovering it.

02

Preserve shared history

Revert adds a compensating commit and avoids changing commit identifiers already used by others.

03

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.

  1. 01
  2. 02
    git log --onelineGit log documentation
  3. 03
  4. 04
  5. 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.

  1. 01
  2. 02
  3. 03
    git branch recovery abc1234Git branch documentation
  4. 04
    git switch recoveryGit switch documentation
  5. 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.