What’s the difference between HEAD, working tree and index, in Git?

A few other good references on those topics:

• My Git Workflow

I use the index as a checkpoint.

When I’m about to make a change that might go awry — when I want to explore some direction that I’m not sure if I can follow through on or even whether it’s a good idea, such as a conceptually demanding refactoring or changing a representation type — I checkpoint my work into the index.

If this is the first change I’ve made since my last commit, then I can use the local repository as a checkpoint, but often I’ve got one conceptual change that I’m implementing as a set of little steps.
I want to checkpoint after each step, but save the commit until I’ve gotten back to working, tested code.

Notes:

1. the workspace is the directory tree of (source) files that you see and edit.

2. The index is a single, large, binary file in <baseOfRepo>/.git/index, which lists all files in the current branch, their sha1 checksums, time stamps and the file name — it is not another directory with a copy of files in it.

3. The local repository is a hidden directory (.git) including an objects directory containing all versions of every file in the repo (local branches and copies of remote branches) as a compressed “blob” file.

Don’t think of the four ‘disks’ represented in the image above as separate copies of the repo files.

• Why Git is better than X

• Git Is Your Friend not a Foe Vol. 3: Refs and Index

They are basically named references for Git commits. There are two major types of refs: tags and heads.

• Tags are fixed references that mark a specific point in history, for example v2.6.29.
• On the contrary, heads are always moved to reflect the current position of project development.

(note: as commented by Timo Huovinen, those arrows are not what the commits point to, it’s the workflow order, basically showing arrows as 1 -> 2 -> 3 -> 4 where 1 is the first commit and 4 is the last)

Now we know what is happening in the project.
But to know what is happening right here, right now there is a special reference called HEAD. It serves two major purposes:

• it tells Git which commit to take files from when you checkout, and
• it tells Git where to put new commits when you commit.

When you run git checkout ref it points HEAD to the ref you’ve designated and extracts files from it. When you run git commit it creates a new commit object, which becomes a child of current HEAD. Normally HEAD points to one of the heads, so everything works out just fine.