CodeOath
← All posts
Git65 min total · 17 parts

Git Internals and Workflows: Branching, Merging, and Rebasing

Contents — Part 3 of 17: HEAD, the Working Tree, the Staging Area, and the Repository
Part 3 of 17 · ~1 min

HEAD, the Working Tree, the Staging Area, and the Repository

Git operates on three distinct layers, and most confusion about "why didn't my change show up" traces back to mixing them up:

AreaWhat it holdsHow to inspect it
Working treeThe actual files on disk, as you're editing themJust look at the files
Staging area (index)Changes marked to go into the next commit, via git addgit status, git diff --staged
Repository (.git history)Committed snapshots, permanent until deliberately rewrittengit log, git show

git add moves a change from the working tree into the staging area; git commit moves everything currently staged into a new permanent commit. git diff (no flags) compares working tree vs. staging area; git diff --staged (or --cached) compares staging area vs. the last commit — two genuinely different comparisons that answer different questions, and mixing them up is a common source of "but I already committed that" confusion.

Detached HEAD

Checking out a specific commit hash rather than a branch name puts you in detached HEAD state — HEAD now points directly at a commit instead of at a branch. Commits made here aren't attached to any branch; if you switch away without creating a branch to hold them first, they become unreachable from any branch (though not immediately deleted — see the reflog chapter near the end). Git warns about this on checkout precisely because it's easy to lose work here by accident.

git checkout a1b2c3d        # detached HEAD, pointing directly at a commit
git switch -c rescue-branch  # create a real branch here before doing anything else