Everything Is an Object
Before understanding commits, branches, or merges, you need to understand Git's object model. Git stores four types of objects in its database, all living in .git/objects/. Every object is identified by the SHA-1 hash of its content.
The four object types:
- Blob — Stores the raw content of a single file. No filename, no metadata — just bytes.
- Tree — Stores a directory listing: filenames, permissions, and pointers to blobs (files) or other trees (subdirectories).
- Commit — Stores a snapshot pointer (a tree), parent commit(s), author, timestamp, and message.
- Tag — An annotated tag object that points to a commit with extra metadata (tagger, message, GPG signature).
These four types compose every piece of information Git tracks. A commit points to a tree. A tree points to blobs and other trees. Blobs hold file content. It's a directed acyclic graph (DAG) of objects.
Commit Object
│
├── tree ──────────────► Tree Object (root directory)
│ │
│ ├── blob ──► Blob Object (README.md content)
│ ├── blob ──► Blob Object (main.go content)
│ └── tree ──► Tree Object (src/ subdirectory)
│ └── blob ──► Blob Object (util.go content)
│
└── parent ────────────► Previous Commit Object
Content-Addressed Storage
The key insight is that object identity is derived from content. If two files have identical content, they share a single blob object. If a directory hasn't changed between commits, the tree object is reused. This is how Git achieves efficiency without explicit deduplication logic — it's a natural consequence of the design.
Git's plumbing lets you inspect any object directly — asking for an object's type, or printing its raw content. Printing a commit object this way shows exactly what it actually stores: a pointer to its tree, a pointer to its parent commit, and author/committer metadata with a timestamp — nothing about what changed, only what the full snapshot looked like and what came before it.
Interviewers sometimes ask: "What is Git, fundamentally?" A weak answer is "a version control system." A strong answer is: "Git is a content-addressable key-value store. Every object — file content, directory structure, commit metadata — is stored under a SHA-1 hash derived from its content. Version control is built on top of this object model." This demonstrates you understand the architecture, not just the commands.
Key Point: Git's object model is the foundation of everything. Blobs store file content, trees store directory structure, commits store snapshots with lineage. All four object types are identified by SHA-1 hashes of their content, enabling automatic deduplication and integrity verification.