Get out of a detached HEAD state
Git says I'm in 'detached HEAD' — what does that mean and how do I fix it?
Short answer
Detached HEAD means you're on a commit rather than a branch. If you made no commits, git switch - takes you back. If you did commit, create a branch at your current position first with git switch -c <name>, otherwise those commits have no reference and become hard to find.
git switch -c my-work # keep the commits you made
# or
git switch - # go back, discarding nothing you committed to a branch
Attach a branch to your current position, or return to where you were
Does this match your situation?
- 'You are in detached HEAD state' appears after a checkout.
- git status says 'HEAD detached at a1b2c3d'.
- git branch shows * (HEAD detached at ...) instead of a branch name.
- You checked out a tag, a commit hash, or a remote branch directly.
Step-by-step fix
Work out whether you've committed anything
This determines everything. If your detached HEAD is still at the commit you checked out, you can just leave. If you've made commits, they belong to no branch and need rescuing first.
step 1git status git log --oneline -5Made commits? Give them a branch immediately
Creating a branch at your current position attaches those commits to a name, which makes them permanent and visible. Do this before switching anywhere else.
step 2git switch -c feature/work-from-detached-head git log --oneline -5Made no commits? Just leave
With nothing to save, returning to a branch is a single command. Nothing is lost because nothing was created.
step 3git switch - # back to the previous branch git switch main # or a specific branchAlready left and lost the commits? Use the reflog
Commits made on a detached HEAD are still in the object database and still listed in the reflog. Find the hash and create a branch at it.
step 4git reflog git branch recovered-work a1b2c3dMerge the rescued work back if you want it
Once the commits are on a branch, they behave like any other work and can be merged or rebased normally.
step 5git switch main git merge feature/work-from-detached-head
Why this works
Normally HEAD points at a branch name and the branch points at a commit, so committing moves the branch forward automatically. When you check out a raw commit, tag or remote-tracking ref, HEAD points straight at the commit instead — that's the detachment. Committing still works, but there's no branch to advance, so the new commits are referenced only by HEAD. The moment you switch away, nothing points at them and they become unreachable, which is why creating a branch first matters so much. It's not an error state: bisect, tag inspection and CI checkouts all use it deliberately.
How to stop it happening again
- Use git switch, which won't detach unless you explicitly pass --detach.
- To work from a tag, branch off it directly: git switch -c fix-1.2 v1.2.0.
- Show detached HEAD in your shell prompt so you notice it right away.
Commands used in this guide
Still stuck?
Search the full command reference and every other rescue guide — there are 56 of them, covering everything from detached HEAD to force-push disasters.
Browse all guides →Frequently asked questions
What does detached HEAD mean in Git?
HEAD is pointing directly at a commit instead of at a branch. You can look around and even commit, but new commits aren't attached to any branch name, so they become unreachable once you switch away. It's a normal state, not an error — bisect and tag checkouts use it deliberately.
How do I keep commits made in a detached HEAD?
Run git switch -c <branch-name> while still detached. That creates a branch at your current commit and attaches all the work to it. If you've already switched away, find the hash in git reflog and run git branch <name> <hash>.
Is detached HEAD dangerous?
Only if you commit and then leave without creating a branch. The commits still exist in the object database and the reflog for weeks, so recovery is usually easy — but there's no reason to rely on that when a single git switch -c avoids the problem entirely.
Related rescue guides
I deleted a Git branch — how do I get it back?
Deleting a branch removes a pointer, not the commits. Find the branch's last commit hash in the reflog and recreate the branch at that hash with git branch <name> <hash>. If the branch was pushed, the copy on the server may still exist and can simply be fetched back.
Read the fix →Usually recoverableI ran git reset --hard and lost my commits — how do I undo it?
Committed work is almost never really gone. git reflog lists every position HEAD has held, including the one just before your reset, so you can jump straight back to it with git reset --hard HEAD@{1}. Uncommitted changes that the reset wiped are a different story — those are only recoverable if they had been staged at some point.
Read the fix →Always fixableI committed to main instead of my feature branch — how do I move the commits?
Create a branch at your current position to keep the commits, then reset the branch you polluted back to where it should be. Nothing is lost because the new branch holds the commits the whole time.
Read the fix →Always fixableHow do I find which commit broke my code?
git bisect binary-searches your history. Tell it one commit that works and one that doesn't; it checks out the midpoint and asks you to test, halving the range each time. With git bisect run it tests automatically and names the guilty commit unattended.
Read the fix →