In Git, what does a commit object actually store?

## The object it points at Git stores four object types, each named by the hash of its own content: **blob** (the bytes of one file version, carrying no name), **tree** (one directory level, listing mode + name + object hash per entry), **commit**, and annotated **tag**. A commit sits on top: it references one tree, and that tree references blobs and subtrees, so a single commit hash transitively identifies every byte of the tracked project. ## The bytes of a commit `git cat-file -p HEAD` prints the object verbatim — a header block, a blank line, then the message: - `tree <hash>` — exactly one line, always. - `parent <hash>` — none for the very first commit, one for an ordinary commit, two or more for a merge. - `author <name> <email> <epoch> <timezone>` — who wrote the change. - `committer <name> <email> <epoch> <timezone>` — who produced this commit object. - optionally `gpgsig` with an inline signature. That is the whole record. Note what is absent: no diff, no list of changed files, no branch name, and no reference to any child commit. Git derives all of those. ## Snapshot, not delta Every commit points at a *complete* tree. Unchanged files are not duplicated, because a tree entry just reuses the existing blob hash, and an unchanged subdirectory reuses its whole subtree. So a snapshot model costs about the same as a delta model while making checkout a direct lookup instead of a replay of patches. When you ask for a diff, Git compares the commit's tree with its parent's tree and reports the entries whose hashes differ. ## Why the hash is an identity The commit id is the hash over the header plus the message. Because the tree hash is inside those bytes, and the parent hash is too, the id commits to the entire history behind it: change an ancestor and every descendant id changes. This is why history rewriting produces *new* commits rather than modifying existing ones, and why an old commit is not destroyed by an amend — it simply becomes unreferenced. ## Author versus committer Both lines exist because Git was built for patches travelling by mail. The author is the person who wrote the change and is preserved when the commit is replayed elsewhere; the committer is whoever created *this* object, and is updated when a commit is rebased, cherry-picked or amended. Two commits with identical trees and messages therefore differ in id whenever these identities or timestamps differ. ## Interview framing The crisp answer is: "tree, parents, author, committer, message — a snapshot plus provenance." Then add the two consequences interviewers are actually probing for: commits are immutable because the id is a hash of the content, and diffs are computed, not stored.