Git internals — what a commit hash actually identifies

Every one of these earlier lessons' concepts — a file's content, a commit's snapshot, a commit's history — is stored as one of exactly four object types, all living in the same object database inside .git. A blob stores a file's raw content. A tree stores a directory's structure — a list of names, each pointing at either a blob (a file) or another tree (a subdirectory). A commit points at one tree (the root of the project at that snapshot) plus its parent commit(s), author, and message. This is the concrete, literal version of the "commits are snapshots" claim from the very first lesson in this domain.

A commit's hash isn't an arbitrary ID assigned by Git — it's a cryptographic hash computed from the commit's actual content, including its parent's hash. This one fact explains several behaviors from earlier lessons directly: changing a commit's message, its content, or its parent produces a completely different hash, because any of those changes the input to the hash function — which is exactly why rebase (from its own lesson) replaying a commit onto a new parent necessarily produces a new hash, even when the actual code changes are identical.

Because each commit's hash incorporates its parent's hash, the commits form a chain where altering anything anywhere breaks every hash after that point — this is what makes Git history tamper-evident: two people comparing the same commit hash can be confident they're looking at bit-for-bit identical history, all the way back, without needing to manually diff every file. Changing history isn't literally forbidden, but doing so is exactly what rebase, reset, and commit-amending all do explicitly — and it visibly changes hashes, rather than silently rewriting content while keeping the same identifier.

The branching lesson's claim that a branch is "a lightweight, movable pointer" isn't a simplification — it's literally true: a branch is a small text file inside .git/refs/heads/, containing nothing but one commit hash. Moving a branch (committing, merging, resetting) means overwriting that one line with a different hash; nothing about a branch involves copying any actual file content, which is the concrete reason branch creation and switching are as fast as they are.

The reflog lesson described commits eventually being cleaned up by git gc after no longer being referenced — this is now the concrete mechanism: gc walks every reachable object starting from every branch, tag, and reflog entry, and anything not reachable that way is safe to delete, since nothing in the repository could ever find it again anyway. This is also exactly why the reflog is what makes recently-orphaned commits recoverable: as long as some reflog entry still points at a commit, gc considers it reachable and leaves it alone.

None of the behavior covered across this entire domain is arbitrary or memorized trivia — every one of these observations is a direct, mechanical consequence of "everything is a hashed object, and refs are just pointers to hashes." Understanding this underlying model is what turns Git's behavior from a list of commands to memorize into something predictable, reasoned out from one consistent mechanism.