Git

Git Detached HEAD State, How to Fix Safely

Seeing "You are in 'detached HEAD' state" isn't an error — it's Git telling you that you're no longer on a named branch, but pointed directly at a specific commit. It only becomes a problem if you make new commits there without realizing it, since those commits can become hard to find later.

The Problem

After checking out a specific commit, a tag, or a remote branch directly, Git shows:

Note: switching to '7a3f9c2'.
You are in 'detached HEAD' state...
git checkout -b <new-branch-name>

If you then make commits while in this state and later switch to another branch, those commits appear to "disappear" — they're not attached to any branch name, so nothing points to them anymore in your usual branch list.

Attached vs Detached HEAD Normal (attached) HEAD -> main Detached HEAD -> commit (no branch name) New commits made here can become unreachable once you checkout elsewhere

Why It Happens

Normally, HEAD points to a branch name (like main), and that branch name points to a commit. When you check out a commit hash, a tag, or a remote branch directly instead of a local branch, HEAD points straight at that commit instead, with no branch name in between. Common ways this happens:

  • Checking out a specific commit hash to inspect old code: git checkout 7a3f9c2
  • Checking out a tag: git checkout v1.2.0
  • Checking out a remote branch directly without creating a local tracking branch: git checkout origin/feature-x

The Fix

If you haven't made any new commits yet, simply checking out any branch name returns you to normal, attached state safely, with nothing to lose:

git checkout main

If you already made commits while detached and want to keep them, create a new branch pointing at your current position before switching anywhere else — this "attaches" your commits to a real branch name so they're safe:

git checkout -b save-my-work

This works even after the fact, as long as you haven't already checked out somewhere else and lost track of the commit hash. If you're not sure whether you have unsaved commits right now, check your current position first:

git log --oneline -5

Compare the commit hashes shown against what you know exists on your actual branches — any commit not visible in git log main (or your usual branch) but visible here is currently only reachable through this detached state.

Still Not Working?

If you already switched away from a detached HEAD and now can't find commits you made there, they're not necessarily gone — Git keeps unreferenced commits around for a while before garbage collection removes them. Use the reflog to find the lost commit hash:

git reflog

Look for the entry corresponding to when you were in the detached state, note the commit hash, then create a branch pointing at it to recover the work:

git checkout -b recovered-work <commit-hash>

The reflog is essentially a local, time-ordered log of everywhere HEAD has pointed recently, including commits made while detached — it's specific to your machine and isn't pushed anywhere, but it's exactly the safety net designed for situations like this one. It typically keeps entries for around 30 to 90 days by default, so unless a significant amount of time has passed, the commit is very likely still recoverable this way.

To avoid running into this in the first place, it helps to build the habit of checking your current state before making any commits, especially right after checking out something unusual like a tag, a specific commit hash, or a remote branch reference. Running git status immediately after any checkout will clearly show HEAD detached at <commit> at the top if you're in this state, giving you a chance to create a branch first with git checkout -b before writing any new commits, rather than discovering the situation only after work is already at risk.

You might also like