HEAD has appeared several times already — the earlier Merge Conflicts lesson's <<<<<<< HEAD marker, and git reset --soft HEAD~1 from Undoing Changes. This lesson explains what it actually is.
HEAD points to whatever commit is currently checked out — normally, that means it points to the tip of the current branch, which itself points to the latest commit.
cat .git/HEAD
# ref: refs/heads/main
# HEAD -> main -> the latest commit on main| Reference | Means |
|---|---|
| HEAD | The current commit |
| HEAD~1 | One commit before HEAD |
| HEAD~3 | Three commits before HEAD |
| HEAD^ | The direct parent of HEAD — equivalent to HEAD~1 for a normal commit |
Normally HEAD points to a branch. Checking out a specific commit directly (rather than a branch name) detaches HEAD from any branch — it now points straight at that one commit instead.
git checkout a1b2c3d
# Note: switching to 'a1b2c3d'.
# You are in 'detached HEAD' state...Looking around in detached HEAD state — checking old file contents, testing something — is completely safe. The risk is committing new changes while detached: those commits exist, but aren't on any branch, and become genuinely hard to find again once something else is checked out.
The real risk of detached HEAD
A commit made in detached HEAD state, with no branch pointing to it, can effectively be lost once HEAD moves elsewhere — Git eventually garbage-collects commits nothing references. To keep work made in this state, create a branch from it before switching away.
# If changes made in detached HEAD are worth keeping, save them to a branch first:
git switch -c rescue-branch
# Otherwise, just return to a normal branch:
git switch main