Undo a changeAlways fixable

Get out of a detached HEAD state

Git says I'm in 'detached HEAD' — what does that mean and how do I fix it?

If you’re seeing this error

You are in 'detached HEAD' state.

HEAD detached at a1b2c3d

You’re in the right place — the fix is below.

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.

quick fix

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 1
```
git status
git log --oneline -5
```
Made 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 2
```
git switch -c feature/work-from-detached-head
git log --oneline -5
```
Made no commits? Just leave
With nothing to save, returning to a branch is a single command. Nothing is lost because nothing was created.
step 3
```
git switch -          # back to the previous branch
git switch main       # or a specific branch
```
Already 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 4
```
git reflog
git branch recovered-work a1b2c3d
```
Merge 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 5
```
git 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

git switch

Move to another branch - the modern, safer half of git checkout.

git branch

List, create, rename and delete branches.

git reflog

The undo history for everything - the single most important recovery command.

git checkout

The old all-in-one: switch branches, restore files, or detach HEAD.

Still stuck?

Search the full command reference and every other rescue guide — there are 76 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

Always fixable

How do I work on two branches at the same time without stashing or re-cloning?

git worktree add ../hotfix main gives you a second folder checked out to a different branch, sharing the same .git object store. No stashing, no second clone, no waiting for your build to reinstall. When you're done, git worktree remove ../hotfix cleans it up.

Read the fix →Usually recoverable

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 →Always fixable

How do I remove a Git submodule — and why does re-adding it say it already exists in the index?

git submodule deinit -f <path>, then git rm -f <path>, then delete .git/modules/<path>. All three matter: deinit clears the config, git rm removes the gitlink and the .gitmodules entry, and the leftover .git/modules copy is what makes re-adding it fail with 'already exists in the index'.

Read the fix →Always fixable

I 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 →

← All Git Rescue guides