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
Data & Performance
- git branch <name>creating a branch from the detached commit pins it to a ref so it survives the next checkoutSource: git-checkout(1) official manual
Key Quotes
In a detached HEAD state you can still create commits, but they're not on any branch and become unreachable once you switch away — rescue them by creating a branch first.
Citations & Further Reading
- Git switch [Official]
- Git checkout [Official]
- Git reflog [Official]
What you will learn
- Understand the core purpose of Rescue work from detached HEAD
- Master the basic usage and common options of 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.
- Understand key concepts: Detached HEAD simply means HEAD points to a commit, not a branch name
- Know when to use this feature and when to avoid it
Start with a problem
You just ran a Git command and the result wasn't what you expected — maybe you even lost some commits. This has happened before, and you want a reliable set of recovery techniques.
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.
Try it yourself
- Practice the detached-head-rescue command in a test repository and observe state changes before and after
- Experiment with different options and compare the output differences
- Simulate a real scenario where you would need to use this, and walk through the full process
Further reading
Keep going on the same topic: