Git, detached HEAD

This post is part of my pre-launch series for my upcoming course Get Really Good at Git launching on May 21. If this post helps you, the course will be a great fit for you, to help you get a much better understanding of Git, reduce your frustrations with it, and figure out the good parts of this incredibly useful tool

One of the states in which your Git repository can end up is “detached HEAD”.

Sounds scary.

Two words: detached (not attached?) and HEAD.

HEAD is the current commit.

When you create a repository, HEAD points to the first commit. If you do a second commit, HEAD points to the new commit.

If you switch branch, HEAD points to the latest commit in that branch.

That’s what’s normal 90% of the time: HEAD points to the latest commit in the currently selected branch. To Git, that’s what it means HEAD being attached.

Our problem is HEAD being detached.

This happens when you checkout a commit that’s not the latest in the branch, and basically means HEAD is not pointing to a branch, but at a commit.

It’s not a situation that’s too unusual. Perhaps you are debugging an issue and you’re trying to figure out in which commit the issue was introduced, so you check out individual commits (using git checkout <commit>) until you find where the code was working.

In this case, when you’re done, you can checkout a branch, for example main, using git checkout main

One thing you can do however is end up in this situation: you are in a detached HEAD state (checked out a commit) and you create a new commit. One or more.

In this case, you need to create a branch before you switch to another branch, otherwise your changes might be lost.

Do so by creating a branch at this commit using:

git branch <new-branch-name>

and then switching to that branch (important):

git checkout <new-branch-name>

Or, with a single command:

git checkout -b <new-branch-name>