Theory

Updated

October 30, 2026

Theory: Snapshots, Names, and a Graph

This chapter is the model the rest of the book assumes. Commands later only add objects and move names.

Invariants

  1. A commit names a complete tree, not a patch. Unchanged files reuse blob hashes.
  2. History is a DAG: each commit points at parent(s). Nothing in the object store is rewritten in place.
  3. A branch is a movable name for one commit. HEAD is a name for “where I am,” usually a pointer to a branch name.
  4. Everyday work uses three trees: working directory, index, HEAD. Status is the report of how they differ.
  5. Distribution means every clone is a repository. A forge is extra software around that fact.
  names (refs)                         objects (content-addressed)
  HEAD → main → C                      C  commit  → tree T → blobs
                ↑                      B  commit
                B ← A                  A  commit

If the name moves and the objects stay, you have not lost history; you have lost a pointer. Reflog (chapter 17) is the local journal of pointer motion.

Why this model

Centralized systems made the server the only full history. Git inverts that: the laptop is complete. Cheap branches follow from “a branch is a file containing a hash.” Integrity follows from hashing content. Hosting platforms, CI, and GitOps cannot escape these invariants; they only add names, ACLs, and jobs.

What can break

  • Treating Git like a file-sync tool (last write wins, no merge).
  • Treating GitHub as Git (issues, Actions, and PRs are forge objects).
  • Committing on a detached HEAD and switching away without a branch name.
  • Assuming git pull is a primitive; it is fetch plus integrate.

How to read this chapter

Landscape is why a VCS. DAG, three trees, objects, refs, and distribution are how Git thinks. Detached HEAD and revision ranges are the first notations you will type. Install and the first repository apply this model on Linux.