How Git thinks

Git makes sense once you know what it stores: snapshots of your files, linked into a history, with movable names pointing into that history. Every command in this sheet moves data between these places.

Repository

Also called repo, .git

What: A project folder tracked by Git. The hidden .git directory holds the whole history, branches and settings; everything else in the folder is your working copy.
Why: Every clone is a full copy of the history, so you can commit, branch and read the log offline and nothing depends on one central machine.

Watch out

Deleting or copying .git by hand, or nesting one repository inside another by accident.

Working tree

Also called working directory, working copy

What: The files you see and edit on disk, checked out from one commit. Git compares them with the index and the last commit to work out what changed.
Why: It is the only place you edit. Commands like git status and git diff describe how it differs from what Git has recorded.

Watch out

Assuming a file is saved in Git because it is on disk: untracked and unstaged changes are lost by git reset --hard or git clean.

Staging area

Also called index, cache

What: A draft of the next commit. git add copies the current content of a file into the index, and git commit turns the index into a commit.
Why: It lets you choose exactly what goes into a commit, even part of a file, so one messy session becomes several focused commits.
Example: You fix a bug and rename a variable in the same file. Stage only the bug-fix lines with git add -p, commit, then stage and commit the rename.

Watch out

Editing a file after git add and committing: the commit contains the staged version, not your latest edit.

Commit

What: A snapshot of the whole project at one moment, plus an author, a message and a pointer to its parent commit (two parents for a merge). It is named by a hash of its contents.
Why: Commits are the unit of history: you review, revert, cherry-pick and bisect them. Because the hash covers the parent too, history cannot be altered silently.

Watch out

Thinking a commit stores a diff. It stores a snapshot; diffs are computed when you ask for them.

Blobs, trees and hashes

Also called object database, SHA

What: Git stores file contents as blobs, folders as trees and snapshots as commits, each addressed by a hash of its content. Identical files are stored once.
Why: Content addressing makes Git fast and compact, and explains why renaming a file costs nothing and why changing an old commit changes every hash after it.

Shell

git cat-file -t HEAD
git cat-file -p HEAD
git ls-tree HEAD
git rev-parse --short HEAD

Branches and refs

Also called ref, branch pointer

What: A branch is just a named pointer to a commit. When you commit on a branch, the pointer moves forward to the new commit. Tags and remote-tracking branches are refs too.
Why: Branches are nearly free to create and delete, which is why Git workflows use one per feature or fix.

Watch out

Thinking deleting a branch deletes its commits. They stay reachable through the reflog for a while, and are only removed once nothing points to them.

HEAD and detached HEAD

What: HEAD is the pointer to what you have checked out, normally a branch name. Checking out a commit or tag directly gives a detached HEAD: you are on a commit, not a branch.
Why: New commits move whatever HEAD points at. On a detached HEAD no branch moves, so work made there is easy to lose.

Shell

git switch --detach v2.1.0
git switch -c hotfix-2-1

Watch out

Committing on a detached HEAD and then switching away. Create a branch first, or recover the commit from git reflog.

Go deeper