Git Internals: Objects, Trees, Blobs and the DAG — How Git Actually Stores Your Data

You've used Git for years. You know the incantations: commit, push, merge, rebase. But when git fsck screams about a missing object at 3 AM, or a corrupted packfile eats your history, your textbook knowledge won't save you. I've seen a junior engineer panic-delete .git/objects because 'it was taking too much space' — that was a fun Monday.

The problem Git solves is deceptively hard: versioning a directory tree efficiently across time, with branching and merging, all while keeping history immutable and verifiable. Before Git, version control systems like SVN stored deltas — changes between versions. That made branching expensive and history fragile. Git flipped the model: store complete snapshots as objects, and let the DAG handle the rest.

By the end of this, you'll be able to recover a corrupted repository by hand, understand why git gc sometimes doubles your repo size, and explain to your teammates why rebasing is just rewriting the DAG. You'll never blindly trust git push --force again.

The Object Store: Content-Addressable Storage

Git's core is a key-value store. The key is a SHA-1 hash of the content; the value is the object itself. This means identical content always produces the same hash — deduplication for free. Objects are stored in .git/objects/ as loose files (one per object) or packed into packfiles.

When you run git add, Git creates a blob object for each file. The blob stores the file content, not the filename. Filenames are stored in tree objects. This separation is critical: renaming a file doesn't change its blob, only the tree that references it.

To inspect an object, use git cat-file -p <hash>. To see its type, use git cat-file -t <hash>. These commands are your window into the object store.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Create a test repo and explore objects
mkdir /tmp/git-internals && cd /tmp/git-internals
git init

# Create a file and stage it
echo "Hello, Git Internals" > README.md
git add README.md

# Find the blob hash
BLOB_HASH=$(git hash-object README.md)
echo "Blob hash: $BLOB_HASH"

# Show the object type and content
git cat-file -t $BLOB_HASH
git cat-file -p $BLOB_HASH

# Now commit to see tree and commit objects
git commit -m "Initial commit"

# Get the commit hash
COMMIT_HASH=$(git rev-parse HEAD)
echo "Commit hash: $COMMIT_HASH"

# Show the commit object
git cat-file -p $COMMIT_HASH

# Show the tree object
git ls-tree -r HEAD

Blobs: The Atomic Unit of Content

A blob is a binary large object — it stores the raw content of a file. Blobs are immutable: once created, they never change. If you modify a file and re-stage it, Git creates a new blob. The old blob remains in the object store until garbage-collected.

Blobs don't store metadata like filename, permissions, or timestamps. That's intentional: it allows Git to deduplicate identical content across files and commits. Two files with the same content share the same blob, even if they have different names.

To create a blob manually without staging, use git hash-object -w <file>. The -w flag writes the object to the store. Without it, you just get the hash. This is useful for scripting and recovery.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

cd /tmp/git-internals

# Create a blob manually
echo "Manual blob content" | git hash-object -w --stdin
# Output: <hash>

# Verify it exists
git cat-file -p <hash>

# Two files with same content share blob
echo "Same content" > file1.txt
echo "Same content" > file2.txt
git add file1.txt file2.txt
BLOB1=$(git hash-object file1.txt)
BLOB2=$(git hash-object file2.txt)
echo "Blob1: $BLOB1, Blob2: $BLOB2"
# Both hashes are identical

Trees: Directory Snapshots

A tree object represents a directory. It contains a list of entries, each with a mode (file type and permissions), a name, and a reference to a blob (for files) or another tree (for subdirectories). The tree is essentially a sorted list of (mode, name, hash) tuples.

Trees are also immutable. When you change a file, Git creates a new tree for the directory containing that file, and recursively for all parent directories up to the root. This is how Git efficiently represents changes: only the affected trees are new; unchanged subtrees are reused.

You can view a tree with git ls-tree <tree-ish>. The tree-ish can be a commit hash, branch name, or tree hash. Use -r for recursive listing.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

cd /tmp/git-internals

# Create a nested structure
mkdir -p src/lib
echo "main code" > src/main.go
echo "library code" > src/lib/helper.go
git add .
git commit -m "Add source files"

# Show the tree for HEAD
git ls-tree -r HEAD

# Show the tree object itself (non-recursive)
TREE_HASH=$(git rev-parse HEAD^{tree})
git cat-file -p $TREE_HASH

# Show subdirectory tree
git ls-tree HEAD:src

Commits: The DAG Nodes

A commit object ties everything together. It contains: a tree hash (root directory snapshot), zero or more parent commit hashes (for merge commits), author/committer info, timestamp, and a message. The parent pointers form the DAG.

A linear history is a chain of commits with one parent each. A merge commit has two or more parents. A root commit (first commit) has no parents. The DAG is directed (parent pointers go backward in time) and acyclic (you can't have a cycle because parent hashes are computed before child).

To see the DAG, use git log --graph --oneline. For a raw view, git cat-file -p HEAD shows the commit object.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

cd /tmp/git-internals

# Create a branch and merge to see DAG
git checkout -b feature
echo "feature work" > feature.txt
git add . && git commit -m "Feature commit"
git checkout main
echo "main work" > main.txt
git add . && git commit -m "Main commit"
git merge feature --no-edit

# View the DAG
git log --graph --oneline --all

# Inspect merge commit
MERGE_HASH=$(git rev-parse HEAD)
git cat-file -p $MERGE_HASH

The DAG: Directed Acyclic Graph in Practice

The DAG is what makes Git powerful. Branching is just creating a pointer to a commit. Merging creates a commit with two parents. Rebasing rewrites history by creating new commits with new parent pointers — the old commits become unreachable and eventually garbage-collected.

Reachability is key: a commit is 'alive' if it's reachable from a ref (branch, tag, HEAD). Unreachable commits are 'dangling' and removed by git gc. This is how Git manages history: you can delete a branch, and its commits vanish from the DAG.

To visualize the DAG, use git log --graph --oneline --decorate --all. For a more detailed view, git rev-list --parents HEAD shows parent hashes.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

cd /tmp/git-internals

# Show parent relationships
git rev-list --parents HEAD

# Find dangling commits (unreachable)
git fsck --lost-found

# Show all refs and their commit hashes
git show-ref

# List all objects reachable from HEAD
git rev-list --objects HEAD | head -5

Packfiles: Efficient Storage for the DAG

Loose objects are fine for small repos, but they waste space and inodes. Git packs objects into packfiles — a single file containing multiple objects, compressed with delta encoding. A packfile has an index (.idx) for fast lookup.

Delta encoding stores a base object and a series of deltas (differences). Git finds similar objects (e.g., consecutive versions of a file) and stores only the differences. This is why git gc can drastically reduce repo size.

To inspect packfiles, use git verify-pack -v .git/objects/pack/*.idx. It shows each object, its type, size, and delta chain. A deep delta chain (e.g., >100) can slow down access. git repack -a -d --depth=250 --window=250 rebuilds the pack with controlled depth.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

cd /tmp/git-internals

# Count loose objects
find .git/objects -type f | wc -l

# Run garbage collection
git gc

# Count objects after GC (should be fewer)
find .git/objects -type f | wc -l

# List packfiles
ls -la .git/objects/pack/

# Inspect packfile contents
git verify-pack -v .git/objects/pack/*.idx | head -20

Refs and Reflog: Navigating the DAG

Refs are pointers to commits. Branches, tags, and HEAD are refs stored in .git/refs/. A branch is a movable pointer; a tag is usually immutable. HEAD is a symbolic ref that points to the current branch (or directly to a commit in detached HEAD state).

The reflog records every movement of HEAD and branch refs. It's a local history of where your pointers have been. git reflog shows the last N actions. This is your safety net: even if you lose a commit from the DAG (e.g., after a reset), the reflog keeps it alive for 90 days by default.

To recover a lost commit, find its hash in reflog and create a branch: git branch recover <hash>.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

cd /tmp/git-internals

# Simulate a lost commit
git reset --hard HEAD~1

# Reflog shows the old HEAD
git reflog

# Recover the commit
LOST_HASH=$(git reflog | head -1 | awk '{print $1}')
git branch recovered $LOST_HASH

# Verify
git log --oneline recovered

Recovering from Corruption: When the DAG Breaks

Corruption happens: disk errors, interrupted git push, buggy Git versions. Symptoms include fatal: bad object, error: packfile .idx mismatch, or fatal: loose object <hash> is corrupt.

First, run git fsck --full to identify all corrupt or missing objects. If a loose object is corrupt, you might recover it from a packfile: git unpack-objects < .git/objects/pack/pack-*.pack extracts all objects, then git fsck again. If a packfile is corrupt, you may need to delete it and re-fetch from a remote.

For a bare repo, git fsck --full is safe. For a non-bare, be careful: git fsck checks the object store, not the working tree. Always have a backup.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

cd /tmp/git-internals

# Simulate corruption: delete a loose object
CORRUPT_HASH=$(git rev-parse HEAD:README.md)
rm -f .git/objects/${CORRUPT_HASH:0:2}/${CORRUPT_HASH:2}

# Run fsck
git fsck --full 2>&1

# Recover from packfile (if object is in a pack)
git unpack-objects < .git/objects/pack/pack-*.pack 2>/dev/null || echo "Object not in pack, need remote"

# If all else fails, re-clone
echo "Recovery failed. Re-clone from remote."

When Not to Use Git Internals Knowledge

You don't need to dive into .git/objects every day. For 99% of operations, git add, git commit, git push are enough. Understanding internals is for debugging, recovery, and advanced workflows (e.g., custom hooks, CI optimizations).

If you're building a tool that manipulates Git objects directly (e.g., a custom merge driver), you need this knowledge. But for everyday development, it's overkill. Don't manually create objects unless you have to.

Also, don't rely on internal formats for backup. Git's object format is stable, but packfile format can change. Always use git bundle or git clone --mirror for backups.