TECH **Git & GitHub: Reflog & Recovering Lost Commits – Zero-Fluff Study Guide**

Git & GitHub: Reflog & Recovering Lost Commits – Zero-Fluff Study Guide

1. What This Is & Why It Matters

What it is:
Git’s reflog (reference log) is a hidden, time-stamped journal of every change to your branch tips (HEAD, main, feature/x, etc.). It records every Git operation—commits, resets, merges, rebases, checkouts—even if those changes don’t appear in git log. Think of it as Git’s "undo history" for your repository’s state.

Why it matters in production:
- You just force-pushed (git push --force) and wiped out a teammate’s work. Without reflog, that commit is gone forever.
- You ran git reset --hard and lost a day’s work. Reflog lets you recover it.
- A rebase went wrong, and now your branch is broken. Reflog helps you rewind to a safe state.
- You accidentally deleted a branch. Reflog can resurrect it.

Real-world scenario:
You’re working on a critical feature branch. A teammate asks you to rebase onto main to clean up the commit history. You run git rebase main, but something goes wrong—conflicts explode, commits disappear, and now your branch is a mess. Without reflog, you’d have to manually reconstruct the lost commits. With reflog, you can undo the rebase in seconds.

2. Core Concepts & Components

• git reflog
• A local-only log of every change to HEAD and branch references.

• Production insight: Reflog is not shared with remote repos. If you lose commits after a git push --force, reflog won’t help unless you have a local copy.

• HEAD@{n}

• A reference to a past state of HEAD (e.g., HEAD@{5} = 5 actions ago).

• Production insight: These references are temporary—they expire after 30 days (configurable via gc.reflogExpire).

• git reflog show <branch>

• Shows the reflog for a specific branch (e.g., git reflog show feature/login).

• Production insight: Useful when debugging branch-specific issues (e.g., "Why did feature/login suddenly point to an old commit?").

• git fsck --lost-found

• Finds "dangling" commits (commits not referenced by any branch or tag).

• Production insight: Slower than reflog but useful if reflog entries have expired.

• git cherry-pick <commit>

• Applies a single commit from reflog to your current branch.

• Production insight: Use this to recover specific lost commits without rewriting history.

• git reset --hard <commit>

• Moves HEAD and working directory to a past commit (destructive).

• Production insight: Always check git reflog before running this—it’s irreversible without reflog.

• git branch <new-branch> <commit>

• Creates a new branch from a reflog commit.

• Production insight: The safest way to recover lost work—no risk of overwriting existing branches.

• gc.reflogExpire (Git config)

• Controls how long reflog entries are kept (default: 30 days).
• Production insight: In high-churn repos, increase this (git config --global gc.reflogExpire "90.days.ago").

3. Step-by-Step: Recovering Lost Commits

Prerequisites

• A Git repo (local or cloned from GitHub).
• Basic Git knowledge (git log, git checkout, git reset).
• No fear of the terminal.

Scenario: You Accidentally Deleted a Commit

You ran git reset --hard HEAD~3 and lost 3 commits. Here’s how to recover them.

Step 1: Check the Reflog

git reflog

Output:

a1b2c3d (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
e4f5g6h HEAD@{1}: commit: Add user authentication
i7j8k9l HEAD@{2}: commit: Fix login bug
m1n2o3p HEAD@{3}: commit: Refactor API client
q4r5s6t HEAD@{4}: checkout: moving from feature/login to main

• Key: The lost commits are e4f5g6h, i7j8k9l, and m1n2o3p.

Step 2: Restore the Lost Commits

Option A: Recover the entire branch (safest)

git branch recovered-branch m1n2o3p  # Create a new branch from the lost commit
git checkout recovered-branch

Option B: Cherry-pick a single commit

git cherry-pick e4f5g6h  # Reapply just the "Add user authentication" commit

Option C: Reset to the lost commit (destructive)

git reset --hard m1n2o3p  # WARNING: Overwrites current branch

Step 3: Verify the Recovery

git log --oneline

Expected output:

m1n2o3p Refactor API client
i7j8k9l Fix login bug
e4f5g6h Add user authentication

Step 4: Push the Recovered Work (If Needed)

git push origin recovered-branch

Scenario: You Force-Pushed and Wiped Out Remote Commits

You ran git push --force and overwrote a teammate’s work. The remote is now broken.

Step 1: Find the Lost Commit in Reflog

git reflog show origin/main  # Check remote-tracking branch

Output:

a1b2c3d (origin/main) HEAD@{0}: push: forced update
e4f5g6h HEAD@{1}: commit: Teammate's critical fix

• Key: The lost commit is e4f5g6h.

Step 2: Recover the Commit Locally

git checkout -b fix-recovery e4f5g6h

Step 3: Push the Fix (Without Force)

git push origin fix-recovery

• Ask your teammate to merge fix-recovery into main.

4. ? Production-Ready Best Practices

Security

• Never disable reflog. Some teams disable it for "cleanliness"—this is a terrible idea.
• Protect main/master with branch protection rules (GitHub/GitLab) to prevent force-pushes.

Reliability & Maintainability

• Increase reflog retention in high-churn repos: bash git config --global gc.reflogExpire "90.days.ago" git config --global gc.reflogExpireUnreachable "30.days.ago"
• Tag important commits (e.g., git tag backup-before-rebase) as a secondary safety net.
• Use git fsck as a last resort if reflog entries expire: bash git fsck --lost-found git show <dangling-commit-hash> # Inspect before recovering

Team Workflow

• Before force-pushing, always:
• git fetch origin
• git log origin/main..main (check what you’re about to overwrite)
• git reflog show origin/main (verify no one else pushed recently)
• Use --force-with-lease instead of --force (fails if remote changed): bash git push --force-with-lease origin main

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "You ran git reset --hard HEAD~3 and lost commits. How do you recover them?"
2. Answer: Use git reflog to find the lost commits, then git branch recovered-branch <commit>.

3. Trap: "Use git log" (wrong—git log only shows current branch history).

4. "A teammate force-pushed to main and overwrote your work. How do you restore it?"

5. Answer: Check git reflog show origin/main, then git checkout -b fix <lost-commit>.

6. Trap: "Clone the repo again" (wrong—this won’t help if the remote is already overwritten).

7. "What’s the difference between git reflog and git log?"

8. Answer: git log shows commit history for the current branch. git reflog shows all changes to HEAD (resets, rebases, checkouts).

9. Trap: "They’re the same" (wrong—reflog is a superset of git log).

10. "How do you prevent accidental force-pushes?"

11. Answer: Use --force-with-lease and enable branch protection rules.
12. Trap: "Don’t use --force" (too restrictive—sometimes force-pushes are necessary).

7. ? Hands-On Challenge

Challenge: Recover a Deleted Branch

1. Create a new branch: git checkout -b temp-work.
2. Make 2 commits:
   bash
echo "test" > file.txt
git add file.txt && git commit -m "First commit"
echo "more work" >> file.txt
git add file.txt && git commit -m "Second commit"
3. Delete the branch: git checkout main && git branch -D temp-work.
4. Recover the branch using reflog.

Solution

git reflog  # Find the commit where temp-work was deleted
git branch temp-work <commit-hash>  # Recreate the branch
git checkout temp-work

Why it works: The reflog records the branch deletion, so you can recreate it from the last known commit.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Git Official Docs – Reflog
2. GitHub Docs – Recovering Lost Commits
3. Atlassian Git Tutorial – Reflog
4. Book: Pro Git (Scott Chacon) – Chapter 10 ("Git Internals") covers reflog in depth.