What is detached HEAD state and how does reflog save you?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
Detached HEAD means you checked out a commit instead of a branch — new commits aren't on any line and risk garbage collection. reflog records every HEAD movement (~90 days default), recovering 'lost' commits after resets, rebases or amends: git reset --hard <reflog-entry>.
Detailed explanation
HEAD normally points at a branch tip; checking out an arbitrary commit detaches it — fine for inspection, dangerous for work: commits made there belong to no branch, invisible in git log of any line, eventually collected. Recovery paths differ by goal: continuing work means creating a branch at that spot immediately (git switch -c new-branch); accidental detachment just needs returning to a named branch. The deeper lesson is reflog: Git journals every reference movement — checkouts, resets, amends, rebases — locally, keeping entries ~90 days. After a disastrous reset --hard or botched interactive rebase, git reflog shows the pre-mistake entry; restore via reset --hard HEAD@{n} or branch from it. This reframes Git psychology: almost nothing committed is ever truly lost — only unreferenced. Committed-but-never-added work (untracked/stashed carelessly dropped) has narrower recovery (fsck --lost-found). Share the mantra: reflog first, panic never.
Example
# Oops — hard reset lost three commits:
git reflog
# abc1234 HEAD@{0}: reset: moving to origin/main
# 8f3e21d HEAD@{1}: commit: add rate limiting ← the one I want
# def5678 HEAD@{2}: commit: add retry logic
git reset --hard HEAD@{1} # everything restored
# Or keep as a branch:
git branch rescue/feature 8f3e21dInterview tip
Define detachment crisply, then perform a live reflog rescue narrative — 'nothing is lost' confidence is exactly what this question tests.
Common mistakes
- Thinking reset --hard permanently deletes commits.
- Committing extensively while detached without branching.