Recovery
Rescue work from detached HEAD
Detached HEAD is not an error by itself. The real risk is creating commits there and leaving them without a branch name that preserves them.
- Anyone actively handling a Git mistake
- Readers who want a conservative rescue habit before trouble happens
- Stop mutating the repo further
- Be ready to inspect `git reflog`, `git status`, and `git log --graph`
- Running more reset or rebase commands before preserving a checkpoint
- Changing shared history before assessing blast radius
Detached HEAD simply means HEAD points to a commit, not a branch name
This often happens when you check out:
- an older commit
- a tag
- a specific object for inspection
That state is not automatically a problem.
The real risk
The risk begins when you:
- make new commits while detached
- switch away again
- forget to attach those commits to a branch
At that point the commits may still exist, but they become easier to lose track of.
If you are still in detached HEAD and the work matters
Create a branch immediately:
git switch -c rescue/detached-head
That single step is often the whole rescue.
If you already left that state
Use reflog first:
git reflog
Find the commit you created in detached HEAD, then attach a branch to it:
git switch -c rescue/detached-head <commit>
How to recognize detached HEAD
Common signs include:
git statusexplicitly says detached HEADgit branch --show-currentprints nothingHEADpoints directly to a commit instead of a branch
When no rescue is needed
If you only inspected an old commit and did not create new commits, you usually do not need a rescue path at all.
You can just return to a branch:
git switch main
The best habit
If you create anything worth keeping while detached, do this immediately:
git switch -c <branch-name>
Name it first, then continue. That keeps detached HEAD from turning into a recovery story.