How Git Works Under the Hood: Blobs, Trees, Commits and Branches

Git is a key-value store wearing a version-control costume

The official Pro Git book describes Git at its core as a content-addressable filesystem. In plain terms, it's a key-value store: you hand Git some content, and it gives you back a key that you can use to fetch that content later. The key isn't a random ID. It's a cryptographic hash computed from the content itself.

That one choice explains a lot. Identical files produce the same key, so Git stores them once. Change one byte and the key changes completely, which lets Git detect corruption just by re-hashing what it reads.

You can see this in action with a plumbing command. Piping text into git hash-object prints the key Git would use for it:

$ echo -n "what is up, doc?" | git hash-object --stdin
bd9dbf5aae1a3862dd1526723246b20206e5fc37

Under the hood, Git doesn't hash your text alone. It prepends a small header, the object type, a space, the size in bytes and a null byte, so the string above is actually hashed as blob 16\0what is up, doc?. Add -w to the command and Git also writes the object to disk, zlib-compressed, under .git/objects/. The first two hex characters of the hash become a folder name and the remaining 38 become the file name.

The objects behind every commit

Everything you've ever committed is built from just a few object types. Here's how they fit together:

Blobs don't know their own names

Filenames live in trees, not blobs. That's why renaming a file without changing it costs almost nothing: the blob stays exactly the same and only the tree entry changes. Tree entries also carry a mode. Pro Git lists the common ones as 100644 for a normal file, 100755 for an executable, 120000 for a symbolic link and 040000 for a subdirectory.

Commits are snapshots, not diffs

Many people assume each commit stores a list of changes. It doesn't. A commit points to a complete tree describing the whole project at that moment. When you run git diff, Git computes the difference on the fly by comparing two trees. The parent line is what links snapshots into history; a merge commit simply has more than one.

Because a commit's hash covers its tree and its parent's hash, changing anything in the past changes every hash after it. That chain is what makes Git history tamper-evident, the same integrity idea that protects data in transit when you connect over HTTPS.

Explore your own repository

You don't need special tools to look around. Try these in any project:

# What does HEAD point to right now?
cat .git/HEAD

# Show the latest commit object, raw
git cat-file -p HEAD

# Show the tree that commit points to
git cat-file -p HEAD^{tree}

# Ask Git what type any object is
git cat-file -t HEAD

The commit output is just a few lines of text: a tree hash, parent hashes, author, committer and message.

Branches, HEAD and tags are just pointers

Hashes are great for machines and terrible for people, so Git adds references: small files that map a friendly name to a hash.

• Branches live under .git/refs/heads/. Each one is a file containing the hash of the latest commit on that line of work. Creating a branch just writes one tiny file, which is why it's instant.
• HEAD is usually a symbolic reference, a pointer to a pointer. Its file typically reads ref: refs/heads/main. When you commit, the new commit's parent is whatever HEAD resolves to, and that branch moves forward.
• Detached HEAD happens when HEAD contains a raw commit hash instead of a branch name, for example after checking out a tag or an old commit. New commits still work, but no branch follows them.
• Tags come in two kinds. A lightweight tag is a reference that never moves. An annotated tag points to a full tag object that records who tagged it, when and why.

This also explains why "lost" work is usually recoverable. A commit you abandoned still exists as an object even when no branch points to it, so you can often find it and point a new branch at it. That makes Git a useful safety net alongside the rollback steps in a disaster recovery runbook.

Packfiles: how Git stays small

If every version of every file were stored as a separate compressed file, big repositories would balloon. Git starts with these "loose" objects, then periodically bundles them into packfiles. Per Pro Git, packing happens when too many loose objects pile up, when you run git gc and when you push to a server.

Each pack comes as a pair: a .pack file holding the objects and an .idx index of offsets so Git can jump straight to any one of them. Inside the pack, Git looks for similar files and stores some versions as deltas, just the differences from another version. Notably, it keeps the newest version whole and stores older ones as deltas, since recent versions are what you access most. You can inspect a pack with git verify-pack -v.

What's changing: SHA-256, reftable and main

Git has always used SHA-1 for object names, but the project is preparing to move on. Git's official BreakingChanges document lists several changes planned for Git 3.0, which doesn't yet have a fixed release date:

1. SHA-256 by default. Newly initialized repositories will use SHA-256 instead of SHA-1. The document says there's no plan to deprecate SHA-1, and the switch depends on libraries, tools and hosting services being ready.
2. Reftable for references. New repositories will store refs in the "reftable" format instead of loose files, which avoids filename collisions on case-insensitive systems and makes bulk and atomic updates faster. You can opt in today with init.defaultRefFormat.
3. A default branch called main. New repositories will start on main, matching what many hosting platforms already use.

Existing repositories keep their current format, so nothing breaks overnight. If you build tooling that parses hashes, though, stop assuming they're always 40 characters: SHA-256 object names are 64.

Frequently asked questions