Chapter 1: Demystifying Git—What Really Happens Under the Hood

Chapter 1: Demystifying Git—What Really Happens Under the Hood

The Magic Behind the Simple Commands

Every developer has been there. You type `git add`, `git commit`, `git push`, and somehow your code safely travels to a remote repository where your teammates can access it. It's almost magical—the way Git seems to understand what you want without much explanation. But here's the uncomfortable truth: most developers use Git daily without truly understanding what's happening beneath the surface. They treat it like a black box, trusting that the right incantations will preserve their work.

This book is going to change that relationship with Git. Not because we'll abandon the convenient commands—those short aliases are genuinely useful—but because understanding the machinery underneath transforms how you approach version control. When you know *why* something works, you can fix it when it breaks. When you understand the *internals*, the exotic commands and recovery techniques stop feeling like arcane rituals and start making perfect sense.

Consider this scenario that plays out in offices worldwide: a developer named Alex accidentally deleted a branch containing three weeks of work. Panic ensues. Their teammate Sam, who understands Git internals, doesn't flinch. "Don't worry," Sam says, "it's in the reflog." Five minutes later, the branch is restored, and Alex is left wondering how that was possible. That knowledge—that branches are just pointers, that deleted branches leave traces, that Git rarely truly deletes anything—is what separates Git *users* from Git *masters*.

This chapter is your foundation. We'll open up Git's hood and examine the engine inside. We'll explore the content-addressable database that stores your project history, understand the four fundamental object types that form the building blocks of version control, trace how Git creates the directed acyclic graph that represents your repository's history, and discover why understanding references and the reflog can save you from countless disasters. By the end, the abstract concepts of "commits" and "branches" will become concrete, tangible things you can see, manipulate, and reason about.

Understanding Git's Architecture: It's Simpler Than You Think

Before diving into specifics, let's build a mental model of Git's overall architecture. At its core, Git is remarkably simple—it stores data, retrieves data, and tracks relationships between pieces of data. That's it. The sophistication comes not from complexity but from the elegance of how these simple operations compose into powerful version control.

Git stores everything in a repository, which is essentially a directory named `.git` sitting in your project's root. Inside this directory, you'll find subdirectories like `objects` (where the actual data lives), `refs` (where Git stores its bookmarks to important commits), and various other metadata files. Everything Git knows about your project is contained within this directory.

What makes Git's storage special is its content-addressable nature. This means that every piece of data is stored not by filename but by its cryptographic hash. When you add content to Git, it computes a SHA-1 hash of that content and stores it using the hash as the address. This approach provides automatic deduplication (identical content is stored only once), integrity verification (you can always verify content hasn't changed by recomputing its hash), and efficient storage (common prefixes in file paths create overlapping storage).

The objects stored in `.git/objects` are the atoms of Git's universe. There are exactly four types, and understanding them thoroughly will unlock your comprehension of everything else. Let's examine each one in detail, starting from the simplest.

Blobs: The Atoms of File Content

A blob (Binary Large Object) is the simplest Git object type. It stores the complete contents of a file—nothing more, nothing less. No filename, no directory path, no metadata about when it was created or who created it. Just pure file content.

This might seem strange at first. If you've ever wondered how Git knows that `file.txt` contains "Hello, World!", the answer lies in the relationship between objects, not within the objects themselves. The blob only knows its content; everything else is tracked through other object types.

When you run a command like `echo "Hello, World!" > file.txt && git add file.txt`, here's what happens:

1. Git reads the file contents: `Hello, World!\n` 2. Git computes the SHA-1 hash of these bytes 3. Git stores the content in `.git/objects` using that hash as the filename

Let's verify this with a real experiment. Create a test directory and follow along:

```bash $ mkdir git-internals && cd git-internals $ git init Initialized empty Git repository in /Users/alex/git-internals/.git/

$ echo "Hello, World!" > file.txt $ git add file.txt ```

Now, let's look at what Git created:

```bash $ find .git/objects -type f .git/objects/8a/b686eafeb1f44702738c8b0f24f2567c36da6d ```

There's our blob. The directory name `8a` and filename `b686eafeb1f44702738c8b0f24f2567c36da6d` together form the SHA-1 hash. You can verify this hash yourself:

```bash $ echo -n "Hello, World!" | sha1sum 8ab686eafeb1f44702738c8b0f24f2567c36da6d - ```

The hash matches! The `-n` flag in echo is crucial—it prevents echo from adding a newline character, giving us exactly the bytes that Git sees.

The git cat-file Command: Your Window into Git Objects

The `git cat-file` command is your primary tool for inspecting Git objects. It can show you the content, type, and size of any object. Let's explore:

```bash $ git cat-file -t 8ab686eafeb1f44702738c8b0f24f2567c36da6d blob

$ git cat-file -s 8ab686eafeb1f44702738c8b0f24f2567c36da6d 14

$ git cat-file -p 8ab686eafeb1f44702738c8b0f24f2567c36da6d Hello, World! ```

The `-t` flag reveals the object type (blob), `-s` shows the size (14 bytes: 13 characters plus the newline), and `-p` pretty-prints the content. Notice that even though we added the file to the staging area, Git has already created the blob object. This is a crucial insight: `git add` creates objects immediately, while `git commit` organizes them into a historical record.

Here's something fascinating to demonstrate deduplication. Create another file with identical content:

```bash $ echo "Hello, World!" > another_file.txt $ git add another_file.txt $ find .git/objects -type f .git/objects/8a/b686eafeb1f44702738c8b0f24f2567c36da6d ```

The object count hasn't changed! Git recognized that `another_file.txt` contains the exact same content as `file.txt`, so it reused the existing blob. This is why Git is so storage-efficient—identical file contents across your entire repository history share the same storage.

Conversely, even a tiny change creates a completely different blob:

```bash $ echo "Hello, World" > different.txt # No exclamation mark $ git add different.txt $ find .git/objects -type f .git/objects/8a/b686eafeb1f44702738c8b0f24f2567c36da6d .git/objects/3c7d44db8c9e5e9c2a4e0e2c7d9e0a2e9c7a2e3d ```

The new file gets its own blob with a distinct hash. This is the cryptographic fingerprint at work—a single changed byte produces an entirely different hash.

Trees: Mapping Directory Structures

If blobs are atoms, then trees are molecules. A tree object represents a single directory level, listing the contents of that directory. Each entry in a tree consists of a mode (file type and permissions), a name, a reference to a blob or subtree, and a hash.

Let's continue our experiment and create a commit to see how trees work:

```bash $ git commit -m "Initial commit" [main (root-commit) a1b2c3d] Initial commit 3 files changed, 0 insertions, 0 deletions ```

Now we have a commit object. Let's examine it:

```bash $ git cat-file -p HEAD tree 7f8a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a author Alex Developer <alex@example.com> 1703123456 -0800 committer Alex Developer <alex@ex