I ended up with a detached head today, the same problem as described in: git push says everything up-to-date even though I have local changes
As far as I know I didn't do anything out of the ordinary, just commits and pushes from my local repo.
So how did I end up with a detached HEAD?
Any checkout of a commit that is not the name of one of your branches will get you a detached HEAD. A SHA1 which represents the tip of a branch still gives a detached HEAD. Only a checkout of a local branch name avoids that mode.
See committing with a detached HEAD
When HEAD is detached, commits work like normal, except no named branch gets updated. (You can think of this as an anonymous branch.)
For example, if you checkout a "remote branch" without tracking it first, you can end up with a detached HEAD.
See git: switch branch without detaching head
Meaning: git checkout origin/main (or origin/master in the old days) would result in:
Note: switching to 'origin/main'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at a1b2c3d My commit message
That is why you should not use git checkout anymore, but the new git switch command.
With git switch, the same attempt to "checkout" (switch to) a remote branch would fail immediately:
git switch origin/main
fatal: a branch is expected, got remote branch 'origin/main'
To add more on git switch:
With Git 2.23 (August 2019), you don't have to use the confusing git checkout command anymore.
git switch can also checkout a branch, and get a detach HEAD, except:
--detach optionTo check out commit
HEAD~3for temporary inspection or experiment without creating a new branch:git switch --detach HEAD~3 HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'
See:
C:\Users\vonc\arepo>git checkout origin/master
Note: switching to 'origin/master'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
Vs. using the new git switch command:
C:\Users\vonc\arepo>git switch origin/master
fatal: a branch is expected, got remote branch 'origin/master'
If you wanted to create a new local branch tracking a remote branch:
git switch <branch>
If
<branch>is not found but there does exist a tracking branch in exactly one remote (call it<remote>) with a matching name, treat as equivalent togit switch -c <branch> --track <remote>/<branch>
No more mistake!
No more unwanted detached HEAD!
I reproduced this just now by accident:
lists the remote branches
git branch -r
origin/Feature/f1234
origin/master
I want to checkout one locally, so I cut paste:
git checkout origin/Feature/f1234
Presto! Detached HEAD state
You are in 'detached HEAD' state. [...])
Solution #1:
Do not include origin/ at the front of my branch spec when checking it out:
git checkout Feature/f1234
Solution #2:
Add -b parameter which creates a local branch from the remote
git checkout -b origin/Feature/f1234 or
git checkout -b Feature/f1234 it will fall back to origin automatically
try
git reflog
this gives you a history of how your HEAD and branch pointers where moved in the past.
e.g. :
88ea06b HEAD@{0}: checkout: moving from DEVELOPMENT to remotes/origin/SomeNiceFeature e47bf80 HEAD@{1}: pull origin DEVELOPMENT: Fast-forward
the top of this list is one reasone one might encounter a DETACHED HEAD state ... checking out a remote tracking branch.
Detached HEAD means that what's currently checked out is not a local branch.
Some scenarios that will result in a Detached HEAD state:
If you checkout a remote branch, say origin/master. This is a read-only branch. Thus, when creating a commit from origin/master it will be free-floating, i.e. not connected to any branch.
If you checkout a specific tag or commit. When doing a new commit from here, it will again be free-floating, i.e. not connected to any branch. Note that when a branch is checked out, new commits always gets automatically placed at the tip.
When you want to go back and checkout a specific commit or tag to start working from there, you could create a new branch originating from that commit and switch to it by git checkout -b new_branch_name. This will prevent the Detached HEAD state as you now have a branch checked out and not a commit.
It can easily happen if you try to undo changes you've made by re-checking-out files and not quite getting the syntax right.
You can look at the output of git log - you could paste the tail of the log here since the last successful commit, and we could all see what you did. Or you could paste-bin it and ask nicely in #git on freenode IRC.
If git was to rename detached HEAD I would have it named as a HEAD that isn’t identified by a branch and will soon be forgotten.
We as people can easily remember branch names. We do git checkout new-button-feature / git checkout main. main and new-button-feature are easy to remember. And we can just do git branch and get a list of all branches. But to do the same with just commits you'd have to do git reflog which is very tedious. Because you have thousands of commits but only very few branches.
A detached commit’s identifier is just its SHA. So suppose you checked out a commit (not a branch) i.e. you did git checkout d747dd10e450871928a56c9cb7c6577cf61fdf31 you'll get:
Note: checking out 'd747dd10e450871928a56c9cb7c6577cf61fdf31'.
You are in 'detached HEAD' state.
...
Then if you made some changes and made a commit, you're still NOT on a branch.
Do you think you'd remember the commit SHA? You won't!
git doesn't want this to happen. Hence it's informing your HEAD is not associated to a branch so you're more inclined to checkout a new branch. As a result below that message it also says:
If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:
git checkout -b
To go a bit deeper a branch is built in a way that it's smart. It will update its HEAD as you make commits. Tags on the other hand are not meant to be like that. If you checkout a tag, then you're again on a detached HEAD. The main reason is that if you make a new commit from that tag then given that that commit is not referenced by anything (not any branch or tag) then still its considered a detached HEAD.
Attached HEADs can only happen when you're on a branch.
For more see here
HEAD is a pointer, and it points — directly or indirectly — to a particular commit:
Attached HEAD means that it is attached to some branch (i.e. it points to a branch).
Detached HEAD means that it is not attached to any branch, i.e. it points directly to some commit.
To look at from another angle, if you're on a branch and do cat .git/HEAD you'd get:
ref: refs/heads/Your-current-branch-name
Then if you do cat refs/heads/Your-current-branch-name then you'd also see the SHA of the commit that your branch is pointing/referencing to.
However if you were on a detached HEAD you and cat .git/HEAD you'd just get the SHA of the commit and nothing more:
639ce5dd952a645b7c3fcbe89e88e3dd081a9912
By nothing more I mean the head isn't pointing to any branch. It's just directly pointing to a commit.
As a result of all this, anytime you checkout a commit (without using the branch name to checkout), even if that commit was the latest commit of your main branch, you're still in a detached HEAD because your HEAD is not pointing to any of your local branches. Hence even checking out a tag will put you in a detached HEAD. To add onto that, even checking out a remote branch that you have fetched into your computer would result in a detached head ie git checkout origin main would also end up as a detached head...
All of the following will cause detached head:
You're only on an attached head, if you've checked out a local branch
Special thanks to Josh Caswell & Saagar Jha in helping me figure this out.
A simple accidental way is to do a git checkout head as a typo of HEAD.
Try this:
git init
touch Readme.md
git add Readme.md
git commit
git checkout head
which gives
Note: checking out 'head'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 9354043... Readme
The other way to get in a git detached head state is to try to commit to a remote branch. Something like:
git fetch
git checkout origin/foo
vi bar
git commit -a -m 'changed bar'
Note that if you do this, any further attempt to checkout origin/foo will drop you back into a detached head state!
The solution is to create your own local foo branch that tracks origin/foo, then optionally push.
This probably has nothing to do with your original problem, but this page is high on the google hits for "git detached head" and this scenario is severely under-documented.
When you checkout to a commit git checkout <commit-hash> or to a remote branch your HEAD will get detached and try to create a new commit on it.
Commits that are not reachable by any branch or tag will be garbage collected and removed from the repository after 30 days.
Another way to solve this is by creating a new branch for the newly created commit and checkout to it. git checkout -b <branch-name> <commit-hash>
This article illustrates how you can get to detached HEAD state.
For my case it happens this way:
git fetchgit checkout origin/feb_debuggingHere it gets me to HEAD is now at....
For fixing I just need another checkout
git checkout feb_debugging
branch-name@{n}, the nth previous position ofbranch-name. But no matter what, at some point there must've been agit checkout <rev>. If that doesn't ring a bell, then probably you did what Will mentioned - tried to dogit checkout <file>and managed to specify a revision by accident. – Cascabelgit status:all conflicts fixed: run "git rebase --continue"– Paulgit checkout remotes/origin/my-branchinstead ofgit checkout my-branchorgit checkout origin/my-branch. – Adam Libuša