Reflog for finding lost commits in Git - Deep Dive

Overview - Reflog for finding lost commits

What is it?

Reflog is a Git feature that records updates to the tip of branches and other references. It keeps a history of where your branch heads and other references have pointed, even if those commits are no longer reachable by normal branch names. This helps you find commits that seem lost after actions like resets or rebases.

Why it matters

Without reflog, if you accidentally delete or move a branch, or reset your HEAD, you might lose track of commits you made. Reflog acts like a safety net, allowing you to recover lost work and avoid costly mistakes. It makes Git more forgiving and helps maintain your project's history intact.

Where it fits

Before learning reflog, you should understand basic Git concepts like commits, branches, and HEAD. After mastering reflog, you can explore advanced Git recovery techniques, stash management, and reflog expiration policies.

Mental Model

Core Idea

Reflog is a hidden diary that remembers every change to your Git references, letting you find commits even after they seem lost.

Think of it like...

Imagine your Git branches as bookmarks in a book. Reflog is like a notebook where you jot down every time you move or remove a bookmark, so you can always find where you were reading before.

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ Commit A   │◄─────│ Reflog Entry│◄─────│ HEAD moved  │
└─────────────┘      └─────────────┘      └─────────────┘
      ▲                    ▲                    ▲
      │                    │                    │
  Branch points        History of          User actions
  here normally      reference changes    like reset, checkout

Build-Up - 6 Steps

1

Foundation

Understanding Git References and HEAD

Concept: Learn what Git references and HEAD are, as reflog tracks their changes.

In Git, a reference (ref) is a pointer to a commit, like a branch name or tag. HEAD is a special ref that points to the current commit you are working on. When you switch branches or make commits, HEAD moves to point to new commits.

Result

You understand that Git references move as you work, and HEAD shows your current position in the commit history.

Knowing that HEAD and refs move with your actions is key to understanding why reflog needs to track these movements.

2

Foundation

What is Reflog and How It Records Changes

Concept: Reflog records every change to Git references, including HEAD, even if those commits become unreachable.

Git automatically saves a log of where HEAD and other refs point after each change. This log is called reflog. It stores entries like 'HEAD moved from commit X to commit Y' with timestamps.

Result

You see that reflog keeps a history of your Git reference movements, not just the commits themselves.

Understanding reflog as a history of ref movements explains how it can help recover lost commits.

3

Intermediate

Using 'git reflog' to Find Lost Commits

🤔Before reading on: do you think 'git reflog' shows only branch tips or all HEAD movements? Commit to your answer.

Concept: Learn how to use the 'git reflog' command to view the history of HEAD and find commits that are no longer on any branch.

Run 'git reflog' in your repository. It lists recent HEAD positions with commit hashes and messages. You can identify commits that disappeared after resets or rebases. To recover, use 'git checkout ' or create a branch at that commit.

Result

You can locate and restore commits that seemed lost by inspecting reflog entries.

Knowing that reflog tracks all HEAD moves lets you recover work even after destructive commands.

4

Intermediate

Recovering Commits After Reset or Rebase

🤔Before reading on: do you think a hard reset deletes commits permanently or just hides them? Commit to your answer.

Concept: Understand how reflog helps recover commits lost after commands like 'git reset --hard' or rebasing.

When you do 'git reset --hard', HEAD moves to a previous commit, and newer commits become unreachable. They still exist in reflog. Use 'git reflog' to find the lost commit hash, then 'git checkout -b recovered ' to restore it.

Result

You can undo destructive resets or rebases by recovering commits from reflog.

Recognizing that commits are not deleted immediately but hidden helps prevent data loss.

5

Advanced

Reflog Expiration and Garbage Collection

🤔Before reading on: do you think reflog entries last forever or expire? Commit to your answer.

Concept: Learn about how reflog entries expire and how Git cleans up unreachable commits over time.

Git automatically expires reflog entries after a default time (usually 90 days). After expiration, unreachable commits may be garbage collected and deleted. You can configure expiration with 'git reflog expire' and control garbage collection with 'git gc'.

Result

You understand the limits of reflog's safety net and how to manage reflog retention.

Knowing reflog expiration prevents surprises when commits disappear after long time periods.

6

Expert

Advanced Recovery Using Reflog and Low-Level Commands

🤔Before reading on: can reflog help recover commits even after branch deletion? Commit to your answer.

Concept: Explore advanced techniques combining reflog with low-level Git commands to recover commits after complex scenarios.

Even if you delete a branch, reflog keeps track of HEAD movements. Use 'git reflog show ' to see its history. Combine with 'git fsck --lost-found' to find dangling commits. You can then create branches or cherry-pick commits to restore lost work.

Result

You can recover commits from complex situations like deleted branches or orphaned commits.

Understanding reflog's integration with Git internals empowers powerful recovery workflows.

Under the Hood

Reflog works by recording every update to Git references in a hidden log file inside the .git directory. Each time HEAD or a branch pointer moves, Git appends a new entry with the old and new commit hashes, timestamps, and a message describing the action. These logs are stored per reference and can be queried to see past states. Garbage collection removes unreachable commits only after reflog entries expire, ensuring safety.

Why designed this way?

Reflog was designed to provide a safety net for users who make mistakes like resets or rebases. Instead of permanently losing commits, reflog keeps a history of reference movements. This design balances performance and safety by storing only reference changes, not full commit histories, and expiring old entries to save space.

┌───────────────┐
│ User Actions  │
│ (commit,     │
│ reset, rebase)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Git Updates   │
│ References    │
│ (HEAD, branch)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Reflog Logs   │
│ (.git/logs/)  │
│ Records old & │
│ new refs      │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Garbage       │
│ Collection    │
│ Removes old   │
│ commits after │
│ reflog expiry │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does 'git reset --hard' delete commits permanently? Commit yes or no before reading on.

Common Belief: Resetting hard deletes commits forever and they cannot be recovered.

Reality: Resetting hard moves HEAD and branch pointers but commits remain in reflog until garbage collected.

Why it matters: Believing commits are gone leads to panic and unnecessary rework; reflog allows recovery.

Quick: Does reflog track only branch tips or all reference changes? Commit your answer.

Common Belief: Reflog only tracks branch tips, not HEAD or other refs.

Reality: Reflog tracks all reference changes including HEAD, branches, and tags.

Why it matters: Misunderstanding limits your ability to find lost commits after actions like checkout or detached HEAD.

Quick: Does reflog keep entries forever? Commit yes or no before reading on.

Common Belief: Reflog entries last forever, so lost commits can always be recovered.

Reality: Reflog entries expire after a default time (e.g., 90 days), after which commits may be garbage collected.

Why it matters: Assuming infinite reflog retention can cause surprise data loss if recovery is attempted too late.

Quick: Can reflog recover commits after deleting a branch? Commit yes or no.

Common Belief: Deleting a branch deletes all its commits immediately and reflog cannot help.

Reality: Reflog records HEAD movements and can help recover commits even after branch deletion until reflog expires.

Why it matters: Knowing this prevents permanent loss from accidental branch deletions.

Expert Zone

1

Reflog entries are stored per reference, so 'git reflog' shows HEAD history, while 'git reflog show ' shows that branch's history separately.

2

Reflog messages include the command that caused the ref update, helping diagnose how commits were lost.

3

You can manually expire reflog entries or disable reflog for specific refs, which affects recovery options.

When NOT to use

Reflog is not suitable for recovering commits after reflog expiration or garbage collection; in such cases, backups or remote repositories are needed. Also, reflog does not track changes pushed to remote repositories; use reflog only for local recovery.

Production Patterns

Teams use reflog to recover from accidental resets or rebases during development. Automated scripts may parse reflog to detect lost commits. Some workflows include regular reflog expiration tuning and backups to balance safety and storage.

Connections

Undo History in Text Editors

Similar pattern of tracking changes to allow undoing actions.

Understanding reflog as a versioned undo history helps grasp its role in recovering lost states.

Database Transaction Logs

Both record sequences of changes to enable rollback and recovery.

Seeing reflog like a transaction log clarifies how Git maintains consistency and recovers from errors.

Forensic Data Recovery

Reflog acts like a forensic trail to find deleted or hidden data.

Knowing reflog's role in data recovery connects Git to broader principles of preserving and restoring lost information.

Common Pitfalls

#1 Assuming 'git reset --hard' deletes commits permanently.

Wrong approach:

git reset --hard HEAD~2
# Then giving up on lost commits

Correct approach:

git reflog
# Find lost commit hash
git checkout -b recovered

Root cause:

Misunderstanding that reset moves refs but does not immediately delete commits.

#2 Ignoring reflog expiration and expecting infinite recovery.

Wrong approach:

# Trying to recover commits months after they were lost
git reflog
# No entries found

Correct approach:

# Regularly check reflog and backup important commits
git reflog expire --expire=never --all
git gc --prune=now --aggressive

Root cause:

Not knowing reflog entries expire and garbage collection removes unreachable commits.

#3 Using reflog only on HEAD and not on other refs like branches.

Wrong approach:

git reflog
# Only checking HEAD history

Correct approach:

git reflog show
# To see branch-specific reflog entries

Root cause:

Assuming reflog is global rather than per reference.

Key Takeaways

Reflog is a hidden log that records every change to Git references, allowing recovery of lost commits.

It acts as a safety net for destructive commands like reset and rebase by tracking where HEAD and branches pointed.

Reflog entries expire after a time, so timely recovery is essential to avoid permanent loss.

Advanced recovery uses reflog combined with low-level Git commands to restore commits after complex scenarios.

Understanding reflog's role helps prevent panic and data loss, making Git safer and more forgiving.

Practice

1. What is the primary purpose of git reflog?

easy

A. To list all remote branches

B. To permanently delete commits from the repository

C. To record where HEAD and branches have pointed recently

D. To merge two branches automatically

Solution

1. Step 1: Understand what reflog tracks

   Reflog records the history of where HEAD and branch references have pointed, including commits that might be lost after resets or rebases.

2. Step 2: Compare options with reflog purpose

   Only To record where HEAD and branches have pointed recently correctly describes reflog's role. Options B, C, and D describe unrelated git functions.

3. Final Answer:

   To record where HEAD and branches have pointed recently -> Option C

4. Quick Check:

   Reflog tracks HEAD history = A [OK]

Hint: Reflog shows recent HEAD moves, like a safety net [OK]

Common Mistakes:

• Confusing reflog with git log
• Thinking reflog deletes commits
• Assuming reflog lists remote branches

2. Which command correctly shows the reflog entries?

easy

A. git reflog

B. git reflog list

C. git reflog -a

D. git reflog --show

Solution

1. Step 1: Recall the basic reflog command

   The simplest and correct command to show reflog entries is git reflog.

2. Step 2: Evaluate other options

   git reflog --show is invalid; git reflog list and git reflog -a are invalid commands.

3. Final Answer:

   git reflog -> Option A

4. Quick Check:

   Basic reflog command = git reflog [OK]

Hint: Use just 'git reflog' to see recent HEAD moves [OK]

Common Mistakes:

• Adding unnecessary subcommands like 'list'
• Using invalid flags like '-a'
• Confusing reflog with git log

3. After running git reset --hard HEAD~1, you realize you lost a commit. Which command helps you find the lost commit's hash?

medium

A. git reflog

B. git status

C. git branch

D. git log --oneline

Solution

1. Step 1: Understand what happens after reset

   git reset --hard HEAD~1 moves HEAD back one commit, making the latest commit unreachable but still in reflog.

2. Step 2: Identify command to find lost commit

   git reflog shows recent HEAD positions including the lost commit's hash. Other commands won't show unreachable commits.

3. Final Answer:

   git reflog -> Option A

4. Quick Check:

   Reflog shows lost commits after reset = C [OK]

Hint: Use reflog to find commits lost by reset [OK]

Common Mistakes:

• Using git status which shows working tree only
• Using git branch which lists branches, not commits
• Using git log which hides unreachable commits

4. You ran git reset --hard HEAD~2 but want to restore the latest commit. Which command correctly resets to the lost commit using reflog?

medium

A. git reset --hard HEAD@{2}

B. git reset --hard origin/main

C. git reset --hard HEAD~1

D. git reset --hard HEAD@{1}

Solution

1. Step 1: Understand reflog indexing

   After resetting HEAD back two commits, reflog entries show HEAD@{0} as current, HEAD@{1} as previous position (the lost commit), and HEAD@{2} as older.

2. Step 2: Choose correct reflog entry to restore

   To restore the latest lost commit, reset to HEAD@{1} which points to it. HEAD@{2} is older, HEAD~1 is relative to current HEAD, and origin/main may differ.

3. Final Answer:

   git reset --hard HEAD@{1} -> Option D

4. Quick Check:

   Use HEAD@{1} to restore last HEAD position [OK]

Hint: Reset to HEAD@{1} to undo last reset [OK]

Common Mistakes:

• Using HEAD@{2} which is older than needed
• Using HEAD~1 which is relative to current HEAD
• Resetting to origin/main which may differ

5. You accidentally deleted a branch with important commits. How can you recover the lost commits using reflog?

hard

A. Run git branch -d to restore the branch

B. Find the commit hash in git reflog and create a new branch at that hash

C. Use git reset --hard origin/branch-name to recover commits

D. Re-clone the repository to get the branch back

Solution

1. Step 1: Locate lost commits in reflog

   Deleted branch commits remain in reflog as recent HEAD positions or branch references before deletion.

2. Step 2: Create a new branch at the lost commit hash

   After finding the commit hash in reflog, use git branch new-branch-name <commit-hash> to restore the branch with lost commits.

3. Final Answer:

   Find the commit hash in git reflog and create a new branch at that hash -> Option B

4. Quick Check:

   Reflog + new branch recovers deleted commits [OK]

Hint: Use reflog hash to recreate deleted branch [OK]

Common Mistakes:

• Trying to delete branch again to restore it
• Resetting to origin which may not have deleted commits
• Re-cloning loses local lost commits