Git Object Model

The Hook (The "Byte-Sized" Intro)

Every file, every folder, every commit in Git is stored as one of just four object types: blobs, trees, commits, and tags. That's it. The entire version control system — branching, merging, history — is built from these four building blocks. Understanding them is like seeing the Matrix: everything suddenly makes sense.

📖 What is the Git Object Model?

Git stores everything as content-addressable objects in .git/objects/. Each object has a unique SHA-1 hash based on its content. There are exactly four types.

Conceptual Clarity

The four object types:

Object	What It Stores	Analogy
Blob	File contents (no name, no path)	A page of text
Tree	Directory listing (filenames → blob/tree SHAs)	A folder/table of contents
Commit	Snapshot pointer + author + message + parent(s)	A labeled photograph
Tag	Annotated tag metadata → commit	A sticky note on a photograph

How they connect:

Commit → Tree → Blob (file1.js)
                → Blob (file2.css)
                → Tree (subfolder/) → Blob (file3.md)

Real-Life Analogy

Git's object model is like a filing system:

Blobs = individual documents (content only, no labels)
Trees = folder labels that list which documents are inside
Commits = timestamped photos of the entire filing cabinet
Tags = sticky notes labeling specific photos as "important"

Visual Architecture

flowchart TD COMMIT["📸 Commit<br/>author, message, parent"] --> TREE["📁 Root Tree"] TREE --> BLOB1["📄 Blob: index.js"] TREE --> BLOB2["📄 Blob: style.css"] TREE --> SUBTREE["📁 Tree: src/"] SUBTREE --> BLOB3["📄 Blob: app.js"] style COMMIT fill:#0f3460,stroke:#53d8fb,color:#53d8fb style TREE fill:#1a1a2e,stroke:#ffd700,color:#ffd700 style BLOB1 fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb style BLOB2 fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb style BLOB3 fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Content-addressable: Same content always gets the same SHA — deduplication is automatic.
Immutability: Objects are never modified, only new ones are created.
Efficiency: Identical files across branches share the same blob object.
Foundation: Every Git command ultimately operates on these four objects.

Code

bash

# ─── Inspect object types ───
git cat-file -t HEAD          # commit
git cat-file -t HEAD^{tree}   # tree
git cat-file -t HEAD:README.md  # blob

# ─── View object contents ───
git cat-file -p HEAD          # Shows commit data
# tree abc123
# parent def456
# author Jane Doe <jane@example.com> 1707840000 +0530
# Initial commit

git cat-file -p HEAD^{tree}   # Shows tree (directory listing)
# 100644 blob abc123    README.md
# 040000 tree def456    src

git cat-file -p HEAD:README.md # Shows blob (file content)
# # My Project
# This is the README.

# ─── Where objects live ───
ls .git/objects/
# 2-char prefix directories containing object files

Key Takeaways

Git has exactly 4 object types: blob, tree, commit, tag.
Objects are content-addressable — their SHA hash is derived from their content.
Objects are immutable — Git never modifies them, only creates new ones.
git cat-file -t shows the type; git cat-file -p shows the content.

Interview Prep

Q: What are the four types of Git objects? A: Blob (file content), Tree (directory listing mapping names to blob/tree SHAs), Commit (snapshot pointer with author, message, parent references), and Tag (annotated tag metadata pointing to a commit).
Q: Why is Git called a content-addressable filesystem? A: Because every object is stored by the SHA-1 hash of its content. The hash IS the address. This means identical content always produces the same hash, enabling automatic deduplication across branches and history.
Q: How does Git store a file's name? A: Blobs don't store filenames — they only contain content. The filename is stored in the parent tree object, which maps names to blob SHAs. This is why renaming a file creates a new tree but reuses the same blob.