Q32 of 40 · Git

Describe the Git object model — blobs, trees, commits, and tags — and explain why this model makes Git operations fast and safe.

GitSeniorgitinternalsobjectsblobstreescommits

Short answer

Short answer: Git stores everything as content-addressed objects (SHA-1/SHA-256). Blobs = file content, trees = directory snapshots, commits = tree + parent + metadata, tags = named commit pointers. Immutability and content addressing make branching, merging, and integrity checks O(1) or O(log n).

Detail

Git's object store is a content-addressed key-value database living in .git/objects/. Every object is identified by the SHA of its content — changing even one byte produces a completely different key.

Blob: stores raw file content (no filename, no path). If two files have identical content, Git stores a single blob. This is why git clone is often faster than you'd expect — deduplication is automatic.

Tree: represents a directory snapshot. A tree object lists entries of the form (mode, type, sha, name) — each entry points to either a blob (file) or another tree (subdirectory). Trees are also content-addressed, so two identical directory structures share the same tree object across commits.

Commit: points to exactly one tree (the root of the working tree snapshot) and zero or more parent commit SHAs. It also stores author, committer, timestamp, and the commit message. The SHA of a commit therefore covers the entire state of the repository at that point.

Tag: an annotated tag is an object that points to a commit (or any other object) with a tag name, message, and optional GPG signature. Lightweight tags are just refs (pointers) with no object.

Why this model is powerful: (1) Branching is free — a branch is just a 41-byte file containing a SHA. (2) Integrity is automatic — if any object is corrupted, the SHA won't match and Git detects it. (3) History is immutable by construction — you can't change a past commit without changing all descendant commit SHAs, which is exactly what rebase/amend does (new objects, new SHAs).

// EXAMPLE

# Inspect the most recent commit object
git cat-file -p HEAD
# tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
# parent a1b2c3d4...
# author Alice Smith <alice@example.com> 1715000000 +0000
# committer Alice Smith <alice@example.com> 1715000000 +0000
# feat: add payment retry logic

# Inspect the tree object from that commit
git cat-file -p 4b825dc642cb6eb9a060e54bf8d69288fbee4904
# 040000 tree abc123  src
# 100644 blob def456  README.md
# 100644 blob ghi789  pom.xml

# Inspect a blob
git cat-file -p def456
# (raw file content of README.md)

# Show the type and size of any object
git cat-file -t HEAD     # → commit
git cat-file -s HEAD     # → size in bytes

# List all objects reachable from HEAD
git rev-list --objects HEAD | head -10

// WHAT INTERVIEWERS LOOK FOR

Accurate description of all four object types. Understanding content-addressing and its implications (deduplication, integrity, immutability). Ability to use cat-file for low-level inspection — this shows real curiosity about Git internals.

// Related questions

Your local Git repository is reporting corrupted objects or a detached HEAD you can't escape. How do you diagnose and recover?

Git

Explain `git reflog` — what it records, for how long, and walk through a scenario where it saves a QA engineer's work.

Git

How do you view the commit history? How do you make it readable?

Git