Git
version control
detached head
commit management
software development

What to do with commit made in a detached head

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

A commit made while HEAD is detached is not broken or invalid. The problem is simply that no branch name points to it yet, so if you move away carelessly the commit can become hard to find later.

The safe response is to create a branch at that commit immediately. If you already switched away, recover the commit through git reflog and then attach it to a branch.

What Detached HEAD Means

Normally, HEAD points to a branch, and that branch points to the latest commit in your line of work. In a detached HEAD state, HEAD points directly to a commit instead of to a branch name.

That often happens after commands such as:

bash
git switch --detach <commit>

or:

bash
git checkout <tag>

If you commit in that state, Git creates the commit normally, but no branch reference moves forward with it.

The Best Fix If You Are Still There

If you are still on the detached commit, rescue it by creating a branch right away:

bash
git switch -c rescue-branch

That does not rewrite the commit. It just creates a normal branch name pointing at it. Once that branch exists, the work is safe and behaves like any other branch tip.

You can confirm the result with:

bash
git log --oneline --decorate -n 3

The new branch name should appear next to the detached commit.

Recovering The Commit After You Left

If you already switched away, use the reflog to locate the commit hash:

bash
git reflog

Look for the commit or the action that corresponds to the lost work. Then create a branch at that hash:

bash
git branch rescue-branch <commit-hash>
git switch rescue-branch

This is the normal recovery path. Detached-head commits are usually still recoverable for some time because the reflog remembers recent reference movements.

Moving The Commit Where It Belongs

After the commit is safely attached to a branch, you can integrate it into the branch where it actually belongs.

If you want to move one commit onto main, cherry-pick it:

bash
git switch main
git cherry-pick <commit-hash>

If the rescue branch contains several commits and should be merged as a unit, merge it instead:

bash
git switch main
git merge rescue-branch

The key idea is that rescue comes first. Integration comes second.

Why You Should Not Panic

Detached HEAD sounds alarming, but it is a normal Git state used for inspection, tagging, and experimental work. The real danger is not the state itself. The danger is forgetting to create a reference to the new commit before moving on.

That is why random cleanup commands are a bad first reaction. The right first step is to anchor the commit with a branch name.

Common Pitfalls

The biggest mistake is running destructive commands such as reset or branch deletion before locating the detached commit. If the work matters, create a branch or inspect the reflog before doing anything else.

Another pitfall is assuming the commit disappeared because git status no longer shows it. Status only describes your current working tree and index, not every commit reachable through the reflog.

A third issue is staying in detached HEAD longer than intended. That is not always wrong, but it increases the chance of creating useful commits that are easy to forget about later.

Summary

  • A detached-head commit is valid, but no branch name points to it yet.
  • If you are still on the commit, rescue it with git switch -c.
  • If you already moved away, find it with git reflog and create a branch from the hash.
  • After the commit is safe, cherry-pick or merge it onto the branch where it belongs.
  • Avoid destructive cleanup commands until the commit is attached to a branch.

Course illustration
Course illustration

All Rights Reserved.