Pro Git

1Snapshots, not diffs — the paradigm shift

Git doesn't store what changed. It stores a picture of everything, every time. "With Git, every time you commit, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot" (p. 14). Other systems (CVS, Subversion) store files plus a series of deltas — to reconstruct version 37, they replay changes from version 1. Git stores version 37 directly. This is why Git doesn't need the server to browse history, why it's fast, and why every clone is a complete backup.

2Everything is checksummed — nothing is lost silently

"Everything in Git is checksummed before it is stored and is then referred to by that checksum" (p. 15). That checksum is a SHA-1 hash: a 40-character hexadecimal string like 24b9da6552252987aa493b52f8696cd6d3b00373. You can't change a file's contents without Git knowing. And Git nearly always adds data — nearly nothing is permanently deleted until you explicitly garbage-collect. The book's phrasing is precise: "It is hard to get the system to do anything that is not undoable." Except git reset --hard.

3The three states and the staging area

Files in Git live in one of three states: modified (changed but not yet staged), staged (marked for the next commit), or committed (safely stored). The staging area is the key: it's a file inside .git/ that stores exactly what will go into the next snapshot. This is what lets you commit only part of your working changes, or build a clean commit from messy work. Most beginners skip it and use git commit -a for years before understanding what they've been bypassing.

git add README.md          # stages one file
git add -p                 # stages parts of files interactively
git commit -m "message"   # commits exactly what was staged

4A branch is a pointer to a commit — nothing more

The book's most clarifying sentence: "A branch in Git is simply a lightweight movable pointer to one of these commits" (p. 64). Creating a branch doesn't copy code, doesn't create a directory, doesn't do much of anything. It writes a 41-byte file (a SHA-1 hash plus a newline) in .git/refs/heads/. That's it. Every time you commit, the pointer moves forward automatically. This explains why branching in Git is instantaneous where it was expensive in Subversion.

# A branch is literally just this file:
$ cat .git/refs/heads/main
ca82a6dff817ec66f44342007202690a93763949

git branch feature     # creates a 41-byte file
git checkout feature   # moves HEAD to point to it

5HEAD is a pointer to a pointer

HEAD is a special file that points to the current branch, which points to the current commit. When you checkout a branch, Git updates HEAD to point to that branch. When you commit, the branch pointer moves, and HEAD follows. This is how Git knows where you are in the history. When you git checkout a specific commit SHA instead of a branch name, you enter "detached HEAD" mode — HEAD points directly to a commit, not to a branch, and any new commits you make won't be attached to any branch.

6The perils of rebasing — and its one rule

Rebase replays your commits on top of another branch, producing a cleaner linear history than merge. The book states its rule bluntly: "Do not rebase commits that exist outside your repository and that people may have based work on. If you follow that guideline, you'll be fine. If you don't, people will hate you, and you'll be scorned by friends and family." The reason: rebasing rewrites SHA-1 hashes. If someone has already based work on those old hashes, force-pushing rebased commits creates contradictory histories that are painful to reconcile.

7Reset demystified: the three trees

The book frames git reset through "three trees" Git manages: HEAD (the snapshot of the last commit), the Index (the proposed next commit = the staging area), and the Working Directory (your actual files). Reset operates on them in sequence, stopping when you tell it to.

"This flag (--hard) is the only way to make the reset command dangerous, and one of the very few cases where Git will actually destroy data" (p. 262). Use it knowingly, not reflexively.

8Git is a content-addressable filesystem

Chapter 10 opens with: "Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it" (p. 414). Everything stored in Git — file contents, trees, commits — is an object addressed by its SHA-1 hash. The .git/ folder contains four things that matter: objects/ (the database), refs/ (named pointers to commits), HEAD (current branch), and index (the staging area). That's all of Git.