Git’s object model is the underlying data structure that stores literally everything in a repository — every version of every file, every folder structure, every commit, every tag — as one of exactly four object types, each identified not by a filename or a sequential number, but by a cryptographic hash of its own content. This is the single most important fact to internalize: Git doesn’t really store “files that changed.” It stores immutable, content-addressed objects, and builds every higher-level concept — commits, branches, history — as relationships between those objects.

Consider a concrete example: a developer named Raj works on a 50,000-line codebase. He changes one line in one file and commits. Git doesn’t rewrite the other 49,999 lines somewhere — it creates exactly one new object for the changed file’s new content, one new object for the folder structure containing it (since that folder’s contents technically changed), and one new commit object tying it all together — while every unchanged file and folder simply reuses objects that already existed from the previous commit. This is the architectural secret behind why Git commits are fast and storage-efficient even in enormous repositories.

Git’s entire object model rests on exactly four object types — nothing else exists at this layer. Every single thing Git tracks is built from some combination of these four.

Notice the clean hierarchy this creates: a commit points to a tree, a tree points to blobs and other trees, and a tag (when annotated) points to a commit. Nothing here is circular, and every relationship flows in one direction — from the abstract (a commit representing “the state of the project”) down to the concrete (a blob holding actual file bytes).

You may likeWhat Is Sparse Checkout?→

The mechanism that ties Git’s object model together is content-addressable storage: every object’s identifier — its SHA hash — is computed directly from that object’s own content, rather than being assigned arbitrarily. This single design decision cascades into nearly every property Git is known for.

Beyond the four object types themselves, a few supporting structures work together to make the object model usable day to day.

Understanding how objects are actually created and connected during a normal commit operation reveals the object model in action.

Notice that steps one through three only ever create new objects for content that’s actually different — any file, folder, or subtree identical to what already existed simply reuses the existing object by its hash, rather than duplicating storage.

flowchart TD
    A["Working directory\nfile edited"] --> B["git add:\ncontent hashed into a blob"]
    B --> C["git commit:\ntree objects built bottom-up"]
    C --> D["Root tree object\nrepresents project state"]
    D --> E["New commit object created\npointing to root tree + parent"]
    E --> F["Branch ref updated\nto new commit hash"]
    F --> G["HEAD follows the branch\nto the new commit"]
    

This diagram is worth studying closely, because it’s the entire mental model condensed into one picture: content flows upward from raw bytes (blobs) through structure (trees) into meaning (a commit), and the only thing that actually “moves” at the end is a small, lightweight pointer — the branch ref — not any of the underlying data itself.

A blob is the simplest of the four object types — deliberately so. It stores exactly one thing: the raw byte content of a single file at a specific point in time.

• No filename is stored inside a blob. The name “config.json” doesn’t exist anywhere in the blob object itself — that association lives entirely in the tree object that references it.
• No file permissions are stored inside a blob either. Whether a file is executable is, again, metadata carried by the tree entry pointing to the blob, not by the blob.
• Identical content always produces the same blob. If two completely different files in your project happen to contain the exact same bytes, they are — at the object level — the exact same blob, referenced from two different tree entries.
• A blob has no concept of “history.” There’s no chain connecting an old version of a file’s blob to its new version — that relationship only exists implicitly, through the commit history that references different blobs for the same filename over time.

A tree object represents a single directory’s structure — a list of entries, each pairing a name and a set of permissions with a pointer to either a blob (a file) or another tree (a subdirectory).

A commit object is where the object model gains meaning as project history. It’s deliberately minimal, but every field it carries is load-bearing.

The parent pointer is what turns a scattered collection of independent commit objects into a coherent, traceable history — each commit knows exactly which commit came before it, and following that chain backward from any commit reconstructs the project’s entire lineage up to that point. A merge commit is structurally identical to any other commit object, except it simply lists more than one parent.

Unlike the other three object types, a tag object is optional — it only exists when you create an annotated tag. A lightweight tag, by contrast, is simply a ref pointing directly at a commit, with no separate tag object involved at all.

An annotated tag object stores its own tagger name, timestamp, and message, entirely separate from the commit it points to — and it can optionally carry a GPG signature, allowing anyone to cryptographically verify that the tag genuinely came from whoever claims to have created it, and that neither the tag’s message nor its target commit have been tampered with since.

Newly created objects start their life as individual, compressed files inside the object database — known as loose objects. But storing millions of tiny individual files becomes inefficient at scale, both in raw disk usage and in filesystem performance, so Git periodically consolidates them.

This distinction is invisible during everyday Git use — commands work identically regardless of whether an object happens to be loose or packed — but it explains why a freshly cloned repository is often far smaller than the sum of every individual change ever made to it: packfiles exploit the enormous similarity between successive versions of the same files.

Once the object model clicks, nearly every familiar Git command reveals itself as a fairly thin operation on this underlying graph. Seeing this mapping explicitly is often the single biggest “aha” moment in understanding Git deeply.

Because the object model’s integrity guarantees rest entirely on cryptographic hashing, understanding its security properties — and their limits — matters for anyone relying on Git for anything security-sensitive.

• SHA-1’s known weaknesses are a real, if narrow, concern. Git historically used SHA-1, which researchers have demonstrated practical collision attacks against — though exploiting this against a real Git repository requires substantial, deliberate effort, not something that happens accidentally.
• Git has since hardened against known collision techniques. Modern Git includes collision detection specifically designed to catch the known attack patterns used in practical SHA-1 collisions, and the project has an ongoing transition path toward SHA-256 for long-term resilience.
• Signed tags and commits provide genuine authenticity guarantees. A GPG-signed tag or commit lets anyone verify not just that content matches its hash, but that a specific, trusted key actually vouched for it — a meaningfully stronger guarantee than hashing alone.
• The object model detects corruption reliably, even without malicious intent. Bit rot, disk errors, or transfer corruption reliably produce a hash mismatch, which Git’s integrity checks will catch, unlike systems that trust stored data blindly.

Because the entire object model is built on verifiable hashes, Git provides direct tools for inspecting and validating the object database itself — invaluable for anyone debugging a corrupted repository or simply trying to see the model in action.

• Build a mental model of the object graph, not just command syntax. Understanding blobs, trees, commits, and refs as a connected structure makes advanced operations (rebasing, cherry-picking, bisecting) far more intuitive.
• Use Git LFS or similar tooling for large binary assets. Keeping the object model doing what it’s good at — text and moderately sized files — avoids the performance and storage pitfalls of forcing large binaries through it directly.
• Treat “history rewriting” operations with appropriate caution on shared branches. Since rewriting history necessarily creates new commit objects with different hashes, anyone else’s local copy referencing the old objects will diverge — understand this before rebasing shared work.
• Periodically run repository maintenance. Letting Git consolidate loose objects into packfiles keeps a long-lived repository efficient, both in disk usage and clone/fetch performance.
• Don’t assume force-deleted history is unrecoverable without checking. Before treating accidentally lost work as permanently gone, check the reflog and the underlying object database — recovery is frequently possible.

A related common mistake worth flagging explicitly: assuming that because a file “looks” different between two commits, an entirely new object had to be created for every level of the containing directory tree, all the way up. In reality, only the directories actually on the path to the changed file get new tree objects — sibling folders elsewhere in the project remain completely untouched and reused, which is precisely why Git’s performance doesn’t noticeably degrade as a repository’s overall size grows, so long as individual changes remain small and localized.