What Detached HEAD Means in Git and How to Fix It

You are working in Git, you check out an older commit to look at old code, and suddenly Git shows a warning about a detached HEAD. The message looks scary, and many beginners worry that they have broken their repository.

The good news is that a detached HEAD is not an error. It is a normal Git state, and you can get out of it safely in less than a minute once you understand what is happening.

In this guide, you will learn what HEAD means, why Git detaches it, and the exact steps to return to a branch or save any work you made while detached.

Quick Answer

A detached HEAD means HEAD points directly to a specific commit instead of pointing to a branch name. You usually get there by checking out a commit hash, a tag, or a remote branch. To get out, run git switch main to return to a branch, or run git switch -c new-branch-name first if you made commits you want to keep.

What Does HEAD Mean in Git?

In Git, HEAD is simply a pointer that tells Git where you are right now. Most of the time, it points to the latest commit on your current branch.

When you are on the main branch, HEAD points to main, and main points to the newest commit. When you make a new commit, the branch moves forward and HEAD moves with it.

This two-step system is why branches are so useful. Your work stays attached to a name that moves automatically as you commit.

Normal HEAD vs. Detached HEAD

In a normal state, HEAD is attached to a branch. You can check this at any time with git status or git branch.

• Attached HEAD: HEAD points to a branch such as main or feature-login. New commits update that branch.
• Detached HEAD: HEAD points directly to one commit hash such as a3f5c21. New commits are not attached to any branch name.

Nothing is broken in the detached state. You can still view files, run your project, and even make commits. The risk is only that unnamed commits are easy to lose when you switch away.

Why Does Git Enter a Detached HEAD State?

Git enters a detached HEAD state when you check out something that is not a local branch. This is intentional, because Git wants to let you explore history without changing your branches.

Here are the most common ways it happens:

1. You run git checkout <commit-hash> to view an older version of your project.
2. You run git checkout v1.2.0 or another tag to test a released version.
3. You run git checkout origin/main instead of your local main branch.
4. You check out a remote branch during a code review to test a teammate’s work.
5. An interactive rebase or bisect session moves you temporarily to a specific commit.

When this happens, Git prints a long warning message that tells you how to save your work before you leave.

If you are still learning the basics, our complete guide to installing Git on Windows 11 walks you through setup and your first repository step by step.

How to Check If You Are in a Detached HEAD State

Before you fix anything, confirm your current state. This takes only a few seconds and prevents mistakes.

1. Open your terminal inside your project folder.
2. Run git status and look at the first line of the output.
3. If it says HEAD detached at a3f5c21, you are in a detached state.
4. Run git log --oneline -5 to see recent commits and note the hash you are on.
5. Run git branch to see your local branches. The current line will show the commit hash instead of a branch name.

How to Get Out of a Detached HEAD Safely

The right fix depends on one simple question: did you make any commits while you were detached? Choose the case below that matches your situation.

Case 1: You Made No New Commits

If you were only looking at old code and did not commit anything, leaving is very simple. You have nothing to lose.

1. Run git status to confirm there are no important uncommitted changes you need.
2. Run git switch main to return to your main branch. Replace main with master or any other branch name if needed.
3. Run git status again. It should now say On branch main.

You can also use the older command git checkout main, which does the same thing. Newer Git versions recommend git switch because it is clearer for beginners.

Case 2: You Made Commits You Want to Keep

If you wrote code and committed it while detached, do not switch away yet. Create a branch at your current commit first, so Git gives your work a name.

1. While still in the detached state, run git switch -c my-recovery-branch. Pick any clear name you like.
2. Run git log --oneline -3 to confirm your commits are now on this new branch.
3. If you want this work in main, run git switch main and then git merge my-recovery-branch.
4. If there are conflicts, resolve them, then run git add . and git commit to finish the merge.

Case 3: You Made Uncommitted Changes Only

Sometimes you edited files but did not commit them yet. Those edits follow you in many cases, but it is safer to save them properly.

1. Run git status to list your changed files.
2. Run git stash push -m "work from detached HEAD" to save the changes temporarily.
3. Run git switch main to return to your branch.
4. Run git stash pop to bring your changes back on the branch.
5. Review the files, then commit them as normal.

What Happens If You Already Switched Away?

If you already left the detached state and fear you lost commits, do not panic. Git usually keeps those commits for a while, and you can often find them again.

Git keeps a log of where HEAD has been. That log is called the reflog, and it is one of the most useful recovery tools in Git.

1. Run git reflog and look for the commit hash from your detached work.
2. Copy the hash, for example git reflog might show a3f5c21 HEAD@{2}: commit: add login fix.
3. Run git switch -c recovered-work a3f5c21, using your real hash, to create a branch at that commit.
4. Check the code with git log --oneline -5, then merge it where you need it.

Act quickly, because Git eventually cleans up unreachable commits. You can read more in the official Git reflog documentation, which explains how long entries are kept.

When a Detached HEAD Is Actually Useful

A detached HEAD is not always something to avoid. You can use it to test an old release, check whether a bug existed earlier, or review a teammate’s commit. The key rule is to create a branch as soon as you want to keep any new work. The official Git checkout documentation also explains the warning message in detail.

Common Mistakes to Avoid

• Switching away without saving commits: If you made commits while detached and switch branches without creating a new branch first, those commits become hard to find.
• Ignoring the warning message: Git tells you exactly how to save your work in that long message. Read it slowly instead of skipping it.
• Confusing remote and local branches: Checking out origin/main detaches HEAD. Use git switch main for your local branch instead.
• Making big changes while detached: Small tests are fine, but do large features on a proper branch from the start.
• Not checking status first: Always run git status before you switch. It takes two seconds and shows you what you might lose.
• Panicking and deleting the folder: A detached HEAD never damages your repository. Never delete and re-clone before trying the reflog.

Conclusion

A detached HEAD simply means you are looking directly at a commit instead of working through a branch name. It is a normal part of Git, not a sign that your project is broken.

If you made no commits, just run git switch main to go back. If you did make commits you need, create a branch first with git switch -c branch-name. With those two commands and the reflog as a safety net, you can explore your history with confidence.

Frequently Asked Questions

Is a detached HEAD dangerous for my project?

No, it is not dangerous by itself. Your existing branches and commits stay safe. The only risk is losing new commits you make while detached if you switch away without creating a branch first.

What is the fastest way to get out of a detached HEAD?

Run git switch main if you have nothing to save. If you have commits to keep, run git switch -c new-branch first, which saves your position as a branch and attaches HEAD again in one step.

Can I still commit while in a detached HEAD state?

Yes, Git allows you to commit in this state, and the commits are real. They just do not belong to any branch, so you should create a branch pointing to them before you move elsewhere.

What is the difference between git switch and git checkout?

Both can move you between branches. git switch was introduced to make branch switching clearer and safer for beginners, while git checkout is the older command that also handles files. Both work for leaving a detached HEAD.

I lost a commit after leaving detached HEAD. Can I get it back?

Usually, yes. Run git reflog, find the hash of the lost commit, and create a branch there with git switch -c recovered-work <hash>. Act quickly, because Git eventually cleans up unreachable commits.