Reflog & Recovery

This lesson on Reflog & Recovery is hands-on and example-driven. You will learn how Git retains history even after destructive actions like hard resets or branch deletions. By mastering the git reflog command, you can locate the hash of any lost commit and safely restore your work into a new branch. This ensures you can recover critical code that was previously thought to be permanently deleted.

What You'll Be Able To Do

• Locate the hash of a deleted commit using the local reference log.
• Restore lost history by creating a new branch pointing to a recovered hash.
• Differentiate between the shared history tracked by git log and the local actions tracked by git reflog.
• Interpret the components of git reflog output, including the Index ID and action description.
• Execute the recovery workflow following an accidental git reset --hard.

Detailed Concept Walkthrough

1. Git Data Persistence Model

Git does not immediately delete committed data; instead, it retains commits that are no longer reachable by any branch or tag pointer. This retention period allows for recovery before the data is permanently removed.

• Mechanism: When a commit is removed from the main history (e.g., by a hard reset), it becomes a "dangling commit" because no reference points to it.
• Under the Hood: Git's internal garbage collection (GC) process runs periodically, typically every 30 to 90 days, to clean up these dangling commits and free up space.
• Best Practice: Recovery must occur before the GC runs, as the commit hash is only valid while the commit object exists locally.

Key Takeaway: Lost commits are retained locally as dangling objects, giving you a window of time for recovery.

2. The Git Reflog Command

The reference log (reflog) is a private, chronological record of every time the HEAD pointer moved in your local repository. It acts as a diary of your personal actions, including destructive ones.

• Mechanism: reflog tracks checkouts, commits, merges, and resets, assigning an Index ID (e.g., HEAD@{5}) to each state change.
• Syntax Rule: The command defaults to tracking the HEAD pointer, but you can inspect other references using git reflog branch_name.
• Output Interpretation: The output provides the commit hash, the Index ID, and the action description (e.g., reset: moving to HEAD~1).
• Best Practice: Use the Index ID (HEAD@{N}) as a temporary pointer to reference a specific state found in the log.

git reflog

# Example output line interpretation:
# 1a2b3c4 HEAD@{5}: commit: Added feature X

Key Takeaway: git reflog is your local safety net, recording every movement of the HEAD pointer, even if the commit is no longer in the main history.

3. Commit Recovery Workflow

Recovery involves using git reflog to find the hash of the desired state and then creating a new, stable reference (a branch) to that hash. This resurrects the lost work without modifying the current history.

• Execution Flow: First, run git reflog to locate the full or partial commit hash (e.g., 1a2b3c4) corresponding to the lost state.
• Best Practice: Always create a new branch from the recovered hash; avoid immediately resetting your current branch, which could lead to further confusion.
• Mechanism: Creating a branch ensures the recovered commit is now reachable by a pointer, preventing the garbage collector from deleting it.

# 1. Find the hash of the lost commit (e.g., 1a2b3c4)
git reflog

# 2. Create a new branch pointing to that hash
git branch recovered_work 1a2b3c4

Key Takeaway: The safest recovery method is to find the lost hash and immediately create a new branch pointing to it.

Topics Covered in Reflog & Recovery

1. Lost History Scenarios (0:00 - 0:34) — Developers often lose work through destructive commands like hard resets or accidental branch deletion.
2. Data Persistence Model (0:36 - 0:54) — Git retains removed commits locally as dangling objects until garbage collection runs, making recovery possible.
3. Role of git reflog (0:55 - 1:13) — The reflog command acts as a local, chronological diary tracking every movement of the HEAD pointer.
4. Log vs. Reflog (1:15 - 1:35) — git log shows shared history, while git reflog shows private, local actions, including destructive ones.
5. Interpreting Output (1:38 - 1:51) — The reflog output provides the crucial commit hash, the Index ID, and a description of the action.
6. Commit Recovery Process (1:53 - 2:22) — The recovery workflow involves finding the lost hash and creating a new branch pointing to that hash.
7. Limitations of Reflog (2:24 - 2:39) — Recovery is impossible if the work was uncommitted, if the repository is new, or if garbage collection has already run.

Git Cheat Sheet

• git reflog — Shows local history of HEAD movements

  git reflog
  

• git reset --hard <hash> — Destructively moves HEAD and discards changes

  git reset --hard HEAD~2
  

• git branch <name> <hash> — Creates a new branch at a specific commit

  git branch safe_point 1a2b3c4
  

• HEAD@{N} — Index ID pointing to a specific reflog entry

  git checkout HEAD@{3}
  

Comparison Table

Common Pitfalls

• Mistake: Assuming reflog tracks uncommitted changes. Avoid: Only committed work is recoverable via reflog.
• Mistake: Expecting reflog history to exist on a fresh clone. Avoid: reflog is strictly local and is not pushed to the remote.
• Mistake: Waiting too long to recover a commit. Avoid: Recover lost work immediately before Git's GC runs.
• Mistake: Using git reset --hard directly for recovery. Avoid: Use git branch <name> <hash> to safely resurrect the commit first.

FAQs

• What is a "dangling commit"? It is a committed object that exists in the repository but is not currently reachable by any branch, tag, or reference pointer.
• Does reflog history get pushed to GitHub? No, the reference log is strictly local to your machine and tracks only your personal actions within that repository clone.
• How long do lost commits remain recoverable? Git's default garbage collection settings typically retain dangling commits for 30 to 90 days before permanent deletion.
• Can I recover work I never committed? No, reflog only tracks movements of the HEAD pointer, which only happens when a commit is created or referenced.