How Git Works Internally: Blobs, Trees, Commits, and the Object DAG (ELIF8 Guide)

Every day, millions of software engineers run git add ., git commit -m "update", and git push hundreds of times.

Yet, when asked what actually occurs inside the hidden .git folder when a commit is created, many developers imagine that Git simply stores a sequence of text file diffs or line-by-line deltas.

In reality, Git is an elegant, lightning-fast Content-Addressable Cryptographic Object Database.

Here is an in-depth, step-by-step masterclass on the internal plumbing of Git.

---

1. The Anatomy of the .git Directory

When you run git init in a fresh terminal directory, Git creates a hidden .git folder containing five essential subsystems:

.git/
├── HEAD             ──► Text file containing pointer to current branch (e.g. ref: refs/heads/main)
├── config           ──► Repository-specific settings, remote URLs, and user email
├── description      ──► Used by GitWeb (mostly legacy)
├── hooks/           ──► Client-side scripts executed before/after commits, merges, and pushes
├── index            ──► The binary Staging Area (tracks file paths, timestamps, and SHA hashes)
├── objects/         ──► The Content-Addressable Object Database (Blobs, Trees, Commits, Tags)
└── refs/            ──► Pointers to branches (refs/heads/) and tags (refs/tags/)

---

2. The Four Fundamental Git Object Types

Inside .git/objects/, Git stores everything as one of four immutable objects, compressed with Zlib and keyed by its SHA-1 (or SHA-256) 40-character hexadecimal hash:

                              [ COMMIT OBJECT ]
                     (SHA: 4a2b9f...)
                     ├── Tree: d81b4f... (Points to Root Directory Tree)
                     ├── Parent: c19a2e... (Previous Commit Hash)
                     ├── Author: Sumit <sumit@vyuhantrix.com>
                     └── Message: "Initial production release"
                                     │
                                     ▼
                               [ ROOT TREE ]
                     (SHA: d81b4f...)
                     ├── 100644 blob e69de2... (package.json)
                     ├── 100644 blob 3b18e5... (README.md)
                     └── 040000 tree a7f29c... (src/ subdirectory)
                                                   │
                                                   ▼
                                            [ SRC SUB-TREE ]
                                  ├── 100644 blob f91b02... (index.ts)
                                  └── 100644 blob 884a11... (utils.ts)

1. The Blob (Binary Large Object)

A Blob stores purely raw file data. It does NOT store the filename, the creation date, or the file permissions! If two different files in different folders have the exact same content, Git stores only one single blob object on disk.

2. The Tree Object (Directories & Filenames)

A Tree corresponds directly to a directory folder. It contains a list of entries, where each entry specifies:

• File mode permissions (100644 for standard file, 100755 for executable, 040000 for directory).
• Object type (blob or tree).
• Object SHA hash.
• The human-readable filename (e.g., README.md or src).

3. The Commit Object (The Historical Snapshot)

A Commit is a small text metadata envelope that glues everything together:

• A pointer to the top-level Root Tree.
• A pointer to one or more Parent Commit Hashes (enabling branching and merge histories).
• Author and Committer names, email addresses, and UNIX timestamps.
• The commit message.

4. The Annotated Tag Object

An Annotated Tag is an immutable cryptographic marker pointing to a specific commit, containing its own tagger name, date, message, and optional GPG signature.

---

3. Hands-On Experiment: Peeking Under the Hood with Plumbing Commands

You can inspect Git's raw cryptographic database using Git's low-level "plumbing" commands:

# 1. Create a raw blob and calculate its SHA-1 hash without touching the staging area
$ echo "Hello Learntrix" | git hash-object -w --stdin
b5f12a32c253de97a9f939e6cf6e153b6f272a2e

# 2. Inspect the type of that object in .git/objects/
$ git cat-file -t b5f12a32c253de97a9f939e6cf6e153b6f272a2e
blob

# 3. Read the decompressed content of that blob object
$ git cat-file -p b5f12a32c253de97a9f939e6cf6e153b6f272a2e
Hello Learntrix

---

4. What is a Git Branch, Really?

In other legacy version control tools (like SVN or CVS), creating a new branch cloned the entire multi-gigabyte codebase into a new directory, taking minutes and wasting disk space.

In Git, a branch is literally a 41-byte plaintext file:

$ cat .git/refs/heads/main
4a2b9f87d3e9185a9bc01824ef78201948ba1204

When you type git branch feature-auth, Git merely writes a 41-byte text file named feature-auth containing the current commit hash! Creating a branch in Git is instantaneous and costs 0 milliseconds of compute and 41 bytes of disk space.

---

5. Packfiles & Delta Compression

If Git stores full snapshot blobs rather than diffs, why doesn't a 5-year-old Git repository with 50,000 commits consume hundreds of gigabytes?

The secret is the Packfile Subsystem (git gc / Git Garbage Collection):

1. As you make commits, loose object files accumulate in .git/objects/.
2. Periodically or during git push, Git scans objects with similar names and sizes.
3. Git compresses them into a single binary .pack file, calculating reverse byte-level deltas (storing the newest version in full, and older historical revisions as tiny binary delta patches).
4. A companion .idx index file allows binary search lookups with microsecond retrieval speeds.

---