How Git Thinks

Git stores each commit as a full snapshot of the project tree, not as a delta from the previous version. This one design choice explains why nearly every Git operation is fast and local: Git is moving pointers to immutable snapshots, not replaying a chain of diffs against a server.

If you come from Subversion or Perforce, this is the mental model to reset. Those systems think in per-file changes against a central server. Git thinks in whole-tree snapshots stored by content hash on your own disk. Internalize that and the rest of Git — cheap branches, instant log, offline everything — stops being surprising.

Snapshots, Not Diffs

Each commit references a tree object that names the exact content of every file at that moment. Files that did not change between commits are not copied — the new tree simply points at the same content as before. So a commit is a complete picture of the project, but storing it costs only the bytes that actually changed, because unchanged content is shared by reference.

The payoff is that checking out any commit is just reading a snapshot, not unwinding a stack of diffs. "Go to the state from three weeks ago" is a direct lookup, which is why it is instant even in a large repository.

Content-Addressable Storage

Git names every object — blob, tree, commit — by the hash of its content. Historically that hash is SHA-1; Git now also supports SHA-256 repositories. Because the name is a digest of the content, identical content always produces the same name and is therefore stored only once. Rename a file and the file's content (the blob) is untouched; only the tree entry that points to it changes.

Content addressing also gives integrity for free. Change a single byte anywhere in history and that object's hash changes, which changes every commit downstream of it. Silent corruption and tampering cannot hide, because the names would no longer match the contents.

The Commit Graph

Every commit points to its parent — two parents for a merge, none for the first commit. That chain of pointers forms a directed acyclic graph, and the history of a project is exactly that graph. Branches and tags are not heavyweight things; they are named pointers into the graph. A branch is a 41-byte file containing one commit hash.

This is why fear of "too many branches" is misplaced. Creating a branch writes a tiny pointer; it does not copy your files. The same operation that takes a server-side directory copy in Subversion is, in Git, instantaneous and local.

Why Operations Are Local and Fast

Because the full object database lives in your .git directory, git log, git diff, git branch, and a checkout all read local files and complete in milliseconds with no network. The network is involved only when you deliberately synchronize with a remote — fetch, pull, push. Everything else is yours, offline.

When you want to see what Git actually stored, git cat-file -p <hash> prints the raw object — a commit's tree and parent, a tree's entries, or a blob's bytes. It is the quickest way to turn the abstract model into something concrete.