What it is: Content hashing is the process of running a piece of data — any file, any block of text, any sequence of bytes at all — through a mathematical function called a hash function, which produces a fixed-length string of characters, called a hash, that acts as a unique fingerprint of that exact content. Change even a single character in the original data, and the resulting hash comes out completely different, in an unpredictable way. Feed the function the exact same content twice, from anywhere, at any time, and it always produces the exact same hash.

Why it exists: Computers frequently need a fast, reliable way to answer the question “is this piece of data identical to that other piece of data?” or “has this piece of data been altered since I last saw it?” — without comparing every single byte of potentially huge files directly, every single time. A hash function answers both questions using a short, fixed-length fingerprint instead, dramatically faster and more practical to work with than the full content itself.

Where it’s used: Content hashing appears throughout computing — verifying downloaded files haven’t been corrupted, detecting duplicate data, and securing passwords, among many other uses. Git is one of the most thorough and foundational applications of this idea: essentially everything Git stores is identified, organized, and connected using content hashes.

Practical example: When you download a large software installer from the internet, the publisher often also provides a short hash value alongside it. After downloading, you can run the same hash function on the file you received and compare the result to the published value. If they match exactly, you can be confident the download completed correctly and wasn’t corrupted or tampered with — all without anyone needing to visually inspect the file’s contents.

When Git was created, its designer needed a system capable of reliably tracking the history of a fast-moving, large, and often widely distributed project — the Linux kernel — where many different people, working on many different computers with no single central authority, needed to be absolutely certain that when they referred to “this exact version of this exact file” or “this exact point in history,” they were all talking about the precise same thing, byte for byte, with zero ambiguity.

A naming system based on simple, sequential numbers or human-assigned labels couldn’t provide that guarantee — two different people working independently could easily create a “version 5” that meant two completely different things. Content hashing solves this elegantly: instead of anyone assigning a name, the content itself generates its own name, deterministically. Two people on opposite sides of the world, working completely independently, who happen to produce the exact same file content, will always compute the exact same hash for it — no coordination required, no ambiguity possible.

The core problem content hashing solves for Git: how do you let many independent people and computers refer to the exact same piece of data with total, mathematically guaranteed certainty, detect any accidental or malicious alteration instantly, and avoid storing duplicate copies of identical content — all without needing any central naming authority at all?

Every single thing Git tracks is stored as one of four kinds of objects, each identified purely by the hash of its own content. Understanding these four object types is the architectural foundation for everything that follows in this guide.

Notice something important here: a blob stores only content, with no filename attached — the filename itself lives in the tree object that references it. This means two completely different files, in two completely different folders, that happen to contain the exact same content, are stored as the exact same single blob internally, referenced from two different places. This is the deduplication benefit of content-addressable storage in direct action.

When Git needs to hash a piece of content — say, the contents of a file you just saved — it doesn’t hash the raw bytes alone. It first constructs a small header containing the object’s type (blob, tree, or commit) and the exact size of the content in bytes, joins that header to the actual content, and then runs the combined result through the hash function. This combination of “type + size + content” is what actually gets hashed, not the content in complete isolation.

flowchart LR
    A["Raw content (a file's bytes)"] --> B["Git builds a header: type and byte-length"]
    B --> C["Header is joined with the content"]
    C --> D["Combined data is run through the hash function"]
    D --> E["A fixed-length hash string is produced"]
    E --> F["That hash becomes the object's permanent identifier"]
    

Step by step, in plain language: first, Git determines what kind of object it’s dealing with — a blob for file content, a tree for a directory listing, or a commit for a snapshot with history. Second, it builds a short header stating that type and the exact byte-length of the content that follows. Third, it concatenates this header directly with the actual content, forming one combined block of data. Fourth, this combined block — not the raw content alone — is passed through the cryptographic hash function. Fifth, the function deterministically produces a fixed-length hash string, and this exact string becomes that object’s permanent name inside Git’s object database, forever, unless the content itself changes.

Notice how each object’s hash depends on the hash of the objects it references — this chaining is the subject of the next chapter, and it’s what gives Git’s history its remarkable integrity guarantees.

Because a commit object’s hash is calculated from content that includes the hash of its parent commit, and a tree’s hash includes the hashes of everything inside it, every single object in Git’s history is linked to the objects it depends on through their hashes, not through separate pointers or references. This creates what’s formally called a Merkle tree (or more precisely, since history can branch and merge, a Merkle directed acyclic graph, often abbreviated Merkle DAG) — a structure where every node’s identity is derived from, and depends on, the identity of everything beneath it.

This Merkle DAG structure is precisely what allows two completely independent copies of a repository — say, yours and a teammate’s — to be compared for differences almost instantly: if the latest commit hashes match, the entire histories underneath are guaranteed to be identical too, without needing to compare a single additional byte.

Because an object’s identity is derived purely from its content, storing the exact same content twice is structurally impossible in Git’s object database — if you compute the hash of content that already exists, you get the identical hash of the object that’s already stored, and Git simply recognizes it needs nothing new to save. This happens constantly and often invisibly: a file that’s renamed but not otherwise changed produces the exact same blob hash as before, so Git doesn’t store a second copy of its content — only a new tree entry pointing at the same existing blob, under the new filename.

This deduplication extends across a project’s entire history, not just its current state. A large file added in an early commit and never modified afterward is stored as one single blob, referenced by every single tree, in every single commit, throughout the project’s entire history that includes it — not duplicated once per commit, which would otherwise make repository sizes grow explosively over time.

Git has historically used a hash function called SHA-1, producing a 40-character hash for every object. SHA-1 was, for many years, considered cryptographically strong enough that finding two genuinely different pieces of content that hash to the exact same value — called a collision — was believed to be computationally infeasible in any realistic scenario. In 2017, however, researchers publicly demonstrated a practical SHA-1 collision, showing that two meaningfully different files could, with enough deliberate, specialized computational effort, be crafted to produce the identical SHA-1 hash.

Git has been developing support for SHA-256 — a hash function from a different, more modern cryptographic family, producing longer, 64-character hashes with substantially stronger collision resistance — as an optional alternative for repositories that want it, alongside continued support for existing SHA-1 repositories. This transition illustrates something important about Git’s content-hashing foundation: the specific algorithm is, in principle, replaceable, but the fundamental architectural idea of content-addressable storage built on hashing remains the same regardless of which specific function is used underneath.

Storing every single version of every file as an entirely separate, independently compressed object would work correctly, but would waste enormous amounts of storage space for projects with a long history of small, incremental changes to large files — even though only a tiny fraction of each file actually changed between versions. Git addresses this with packfiles: a storage optimization where many objects are bundled together into a single file, with similar objects stored as small deltas — compact descriptions of just the differences from a similar, already-stored object — rather than each one being stored as a fully independent, complete copy.

This is also directly why pushing and cloning repositories over the network is efficient: Git can identify exactly which object hashes the other side is already missing, and transfer only those specific, often delta-compressed objects, rather than the entire repository’s full history every single time.

When you push to GitHub, you’re not uploading an entirely new copy of your project every time — you’re transferring specific, hash-identified objects that GitHub’s copy of the repository doesn’t already have, exactly as described in Chapter 9. GitHub’s servers store and serve these same hash-addressed objects, which is precisely why a commit hash you see locally, in your terminal, is the exact same commit hash you’ll see displayed on GitHub’s website — it’s not a separately generated identifier assigned by GitHub, but the actual, portable, mathematically derived identity of that specific commit, valid and identical anywhere Git is used.

This also explains why a link to a specific commit on GitHub is so permanently reliable: because that link contains the commit’s hash, and that hash is mathematically derived from the entire content and history it represents, the content behind that link can never silently change while keeping the same hash — any alteration would produce a different hash and, therefore, a different link entirely.

A hash proves that a piece of content is exactly what it claims to be, byte for byte — but it says nothing about who actually authored it, since anyone could compute the hash of any content. To add genuine authorship verification, Git supports signed commits and signed tags: using a separate cryptographic signature — created with a private key only the actual author possesses — applied on top of the commit or tag’s own hash.

When someone verifies a signed commit, two distinct checks happen together: first, confirming the commit’s hash genuinely matches its content (the integrity guarantee hashing provides on its own), and second, confirming the attached signature was genuinely created by the claimed author’s private key (the authenticity guarantee signing adds on top). GitHub displays a “Verified” badge on commits where this full check succeeds, giving anyone browsing the repository visible, trustworthy confirmation of both properties at once.

The core trade-off to internalize: content hashing trades a small amount of computational overhead and some conceptual complexity for extraordinarily strong, mathematically grounded guarantees about data integrity and efficient storage — guarantees that would be very difficult to achieve as reliably through any simpler, name-based system.

Computing a hash for every object does add real processing work, but modern hash functions are engineered to run extremely fast on ordinary hardware — for the vast majority of everyday development, this overhead is imperceptible compared to the time spent on other tasks. Where hashing’s performance impact becomes more noticeable is at genuine scale: a repository with an extremely long history and enormous, frequently changing files can involve a large volume of hash computation and comparison during operations like cloning or checking out a large amount of history at once.

The packfile and delta-compression mechanisms covered in Chapter 9 exist specifically to keep this scalable — by storing and transferring compact deltas rather than full copies wherever content is similar, Git keeps both storage size and network transfer time far smaller than a naive, fully-duplicated approach would require, even for projects with years of accumulated history.

For teams working with genuinely enormous binary files — video assets, large datasets — Git’s content-hashing model, while still technically correct, can become less efficient than purpose-built alternatives, which is exactly why specialized extensions exist to handle very large files differently while still integrating with Git’s core hash-based architecture.

You may likeWhat Is Git Rerere?→

As covered in Chapter 8, while a practical SHA-1 collision has been demonstrated, exploiting it meaningfully against a real Git repository remains a significant, specialized undertaking, and Git includes detection safeguards against known collision-attack patterns. Nonetheless, security-conscious projects benefit from combining content hashing with the authorship verification that signed commits and tags provide, as covered in Chapter 11, rather than relying on hash integrity alone as a complete trust story.

It’s also worth understanding that because Git’s object model deduplicates identical content, sensitive information accidentally committed once — even if later “removed” in a subsequent commit — often remains fully recoverable from the object database, since removing a file from the latest snapshot doesn’t delete the underlying blob object still referenced by earlier history. Truly removing sensitive content requires deliberately rewriting history to eliminate the object itself, not simply committing its deletion going forward.

The Hash-as-Immutable-Reference Pattern deliberately references specific commit hashes — rather than mutable branch names — when absolute certainty about exact content matters, such as in a deployment record or a security audit trail, relying precisely on the guarantee that a given hash can never silently point to different content.

The Signed-Release Pattern combines commit hashing with cryptographic signing, as covered in Chapter 11, specifically for published releases, giving downstream users both integrity and authorship guarantees together rather than integrity alone.

Common anti-patterns to avoid: the Hash-Blind Trust pattern (assuming a matching hash alone means content is safe, ignoring that integrity and trustworthiness are different properties, as covered in Chapter 14); the Deletion-as-Removal misunderstanding described above; and the Manual Hash Comparison anti-pattern (visually eyeballing long hash strings instead of using tooling to compare them programmatically, an error-prone habit given how easy it is to miss a single differing character in a 40- or 64-character string).

Common mistakes beginners make: assuming a matching hash alone proves content is trustworthy rather than merely unaltered; believing a later “delete” commit genuinely removes sensitive data from a repository’s history; and underestimating just how much of Git’s everyday behavior — deduplication, efficient network transfer, reliable history comparison — traces directly back to this one foundational, content-hashing design decision.