Git internals: learn the model, and the commands become obvious.

Git's foundation is one decision: every piece of data is named by the hash of its content. Store a file, and its bytes are hashed; that hash IS the file's identity, forever. Two consequences do enormous work. Deduplication is automatic — a thousand commits containing the same unchanged file store its blob exactly once. And nothing can be silently corrupted or edited — change a single byte anywhere and every hash above it changes, which is why Git can verify an entire repository's integrity by checking one hash.

Note what a commit is not: a diff. Every commit is a full snapshot — a pointer to a complete tree. Diffs are computed on demand by comparing two trees. This is why checkout of any ancient commit is instant (follow one pointer), and why Git needs packfiles (section 07) to keep full-snapshot storage cheap.

Run cat .git/refs/heads/main. You'll see one commit hash and a newline — 41 bytes. That file is the branch. There is nothing else. "Creating a branch" writes this file. "Committing" appends an object and rewrites this file with the new hash. "Deleting a branch" deletes the file — the commits remain, merely unlabeled.

HEAD is one more level of indirection: a file usually containing ref: refs/heads/main — a pointer to a pointer, marking "where you are." The infamous detached HEAD is simply HEAD containing a raw commit hash instead of a ref name. Nothing is broken; you're just standing on a commit rather than riding a branch — and any commits you make there are reachable only via the reflog until you name them.

Git juggles three snapshots at all times: HEAD (last commit), the index (staging area — the next commit, prebuilt), and the working directory (your actual files). Every day-to-day command is a synchronization between them:

This table is the entire mystery of reset: the three flags are just how far the sync propagates. And add -p stops feeling exotic — you're editing the index, a real, inspectable snapshot (git diff --staged shows it) that exists so you can compose a commit deliberately instead of committing your whole messy desk.

Merge is honest arithmetic on the DAG: find the common ancestor (merge base), three-way compare both sides against it, combine, and record a commit with two parents. History stays true — the fork happened, the join happened, the graph says so.

Rebase is rewriting: take your commits since the fork, and replay them one at a time on top of the new base. Each replayed commit has a different parent and timestamp — so it hashes to a new commit. The old ones aren't modified (nothing ever is); they're abandoned, and your branch file now points at the copies.

Same logic explains --force-with-lease: a rewritten branch no longer fast-forwards, so pushing needs force — and the lease makes force safe by refusing if the remote moved since you last looked (i.e., a teammate pushed).

Here's the fact that turns Git panic into Git calm: objects are never edited and almost never deleted. Reset "back" in history? The commits ahead still exist — unlabeled. Botch a rebase? The originals still exist. Git additionally keeps a private journal — the reflog — of every position HEAD has occupied, for ~90 days.

Garbage collection eventually prunes objects nothing references — but "eventually" is weeks away by default. The honest statement of Git safety: anything you ever committed is recoverable for months; only never-committed working-directory changes can truly vanish (reset --hard and restore are the two genuinely dangerous commands).

A remote is just someone else's object database plus their refs. fetch downloads their new objects and updates your remote-tracking refs (origin/main — your read-only bookmark of their state); pull is fetch + merge (or rebase) into your branch; push uploads your objects and asks the remote to move its ref — refused unless it's a fast-forward, hence the force flags. All the sync commands are pointer diplomacy between two object stores.

And the storage trick that makes full-snapshot commits affordable: loose objects are periodically compressed into packfiles, where similar objects are stored as deltas against each other. Snapshots in the model, diffs on the disk — each layer choosing the representation that serves it best. It's the same play databases run with WALs and B-trees, and it's why a 15-year repo with 100K commits fits in a coat pocket.