Your Branch Is 41 Bytes (Git Internals Explained)

Installing mental model for Git.

You've used Git almost every day of your career. Git add, git commit, git push. But here's the thing — most developers have the wrong picture of what's happening under the hood.

In a poll of experienced developers, fifty-one percent said Git stores the differences between versions. A chain of patches, one after another.

That's not what's happening.

Git's data model is built on snapshots. Every single commit captures the complete state of your project. Every file, every folder, frozen in time.

But if every commit stores everything, wouldn't that be enormous? No — because Git hashes every piece of content. If two files are identical across commits, they produce the same hash. Stored once, referenced everywhere. The snapshots are cheap because most files don't change.

So if Git's model is snapshots, how does it actually organize them?

At its core, Git is a key-value store. You give it content, it hashes it, and stores the result as an object. The simplest object is a blob — raw file contents. No filename, no metadata. Just bytes and a hash.

A project has files with names arranged in folders. So Git uses a second object called a tree. A tree maps filenames to blob hashes, and sub-directories are just trees pointing to other trees.

And a commit? A commit points to the root tree — the complete snapshot — plus its parent commits, and metadata like who made it and when.

Three types of objects. All connected by hashes. That's what Git is made of.

And because every commit records its parents, the commits form a graph. Not a straight line — a graph. Branches split off, merge back together, and every node knows exactly where it came from. This is what Git actually looks like under the surface.

So Git is a graph of objects. But how do humans navigate a graph? With labels. And Git's labels are shockingly simple.

Open up your .git folder. Navigate to refs, heads, main. Open that file. You'll find one line — forty characters of hexadecimal and a newline. Forty-one bytes. That is your main branch.

A branch in Git is just a tiny text file containing a commit hash. That's it. Creating a new branch doesn't copy code or duplicate history. It writes a hash to a new file. This is why branching in Git is nearly instant, even on massive projects.

And HEAD? HEAD is another pointer. Usually it points to a branch name, telling Git which branch you're on. When you make a commit, Git updates that branch file — the pointer moves forward.

So when you commit, Git snapshots your staged changes into a tree, wraps it in a commit object, and moves the branch pointer forward. Add, snapshot, move pointer. That's the whole cycle.

Once you see this — objects and pointers — everything else falls into place. Rebase, cherry-pick, the reflog — they're all operations on this same graph. But that's the next video.

Cognitive architecture... updated.