pro-git

Pro Git

Derived from Pro Git, 2nd edition, by Scott Chacon and Ben Straub, licensed CC BY-NC-SA 3.0 (https://creativecommons.org/licenses/by-nc-sa/3.0). This distillation carries the same license.

The book covers the CLI from first principles. Chapters 1–3 teach the model, 4–6 cover collaboration, 7–8 cover power tools and customization, 9 covers other VCSs and 10 covers internals. Load a chapter file when a question needs its detail. The models below answer most "why does Git do that?" questions.

Core mental models

1. Snapshots, not deltas. Each commit records the full state of the project. Unchanged files are stored as references to the copy Git already has. Bringing a CVS/SVN "list of file changes" mental model into Git is the root of most confusion. → Ch1
2. Nearly everything is local, and content is checksummed. The full history lives in your clone, so log, diff and commit work offline. Everything is addressed by SHA-1, so silent corruption is detectable. Git mostly adds data: anything committed is very hard to lose. Uncommitted work has no such protection.
3. Three states and three trees. A file is modified (working tree), staged (index) or committed (Git directory/HEAD). git add stages the content as it is at that moment. Edit the file again and it is both staged and unstaged. git diff compares working tree with index; git diff --staged compares index with last commit. → Ch2
4. A branch is a 41-byte file holding a commit SHA-1; HEAD points to the current branch. Branching is nearly free, and committing moves the current branch forward. A fast-forward merge just moves a pointer. A diverged merge is a three-way merge (two tips plus their common ancestor) and makes a commit with multiple parents. → Ch3
5. Remote-tracking branches are bookmarks. origin/master records where the remote was at your last fetch, and only network operations move it. fetch only downloads. pull = fetch + merge (or rebase). A push is refused when someone pushed first, because Git never merges on the server.
6. Merge vs rebase gives the same snapshot and a different story. Rebase replays commits to make linear history and creates new commits. The rule: rebase local work before pushing, and never rebase commits others may have built on. → Ch3, Ch5
7. reset is three steps. (1) Move the branch HEAD points to: --soft stops here. (2) Make the index match: the default --mixed stops here. (3) Make the working tree match: only --hard, the one form that can destroy uncommitted work. With a path, step 1 is skipped. checkout/switch moves HEAD itself, while reset moves the branch under it. → Ch7
8. Rewriting changes SHA-1s. Amend, rebase -i, filter-branch and reset rewrite the target commit and every commit after it. For shared history use git revert (-m 1 for a merge) instead.
9. Git is a content-addressable store. Blobs hold file contents with no names. Trees map names to blobs and subtrees. Commits point to a tree, parents and author info. Tags point to objects. Refs are files naming SHA-1s. Objects start loose and get delta-compressed into packfiles. Anything reachable stays in every clone, so removing a big file means rewriting history. → Ch10
10. Hooks are local convenience; server hooks are policy. Client hooks are not cloned and --no-verify bypasses them. Enforce rules in pre-receive/update on the server. → Ch8