That's not because Git is complicated. It's because we usually learn Git as a set of commands, not as a system. Once you see what Git actually stores and how it links things together, it stops feeling like magic.

The shift that makes Git click

Here's the idea that changes everything: Git is a content-addressable database. It stores data, computes a cryptographic hash for that data, and uses those hashes as addresses. Objects reference other objects by hash, which gives Git immutability, cheap snapshots, and global deduplication.

The 3 building blocks of Git

Everything in Git is built from three object types.

1. Blob — file contents

   • A blob is just the raw contents of a file.

   • No filename, no mode, no metadata — just the bytes.

   • If two files have identical contents, Git stores only one blob and reuses it.

   Example:

   echo "hello world" > a.txt
   # write the blob to the object database and print its hash
   git hash-object -w a.txt
   # inspect contents of the object
   git cat-file -p <blob-sha>
   

   If you create another file with the same content and run git hash-object -w on it, you’ll get the same SHA.

2. Tree — directory snapshot

   • A tree records filenames → blob SHA and subdirectory names → tree SHA.

   • Think of a tree as a snapshot of a directory structure (file names and modes included).

   Examples:

   # show the tree for the current commit
   git ls-tree HEAD
   
   # after staging files, create a tree object
   git add .
   git write-tree   # prints a tree SHA
   
   # inspect the tree contents
   git cat-file -p <tree-sha>
   

3. Commit — snapshot + metadata

   • A commit points to a tree and records metadata: author, committer, message, timestamp, and 0+ parent commit SHAs.

   • A commit is not a "diff" or a set of changes — it's a pointer to a full snapshot (the tree) plus context about how that snapshot was created.

   Example:

   # create a commit object that points to an existing tree
   git commit-tree <tree-sha> -p <parent-sha> -m "Message"
   # inspect the commit
   git cat-file -p <commit-sha>
   

Look under the hood: plumbing commands

Porcelain commands (git add, git commit, git checkout, etc.) are convenient high-level commands. Underneath them, Git uses lower-level "plumbing" commands you can use to inspect and manipulate objects directly.

Useful plumbing commands:

git hash-object  # create a blob (optionally write to object DB with -w)
git cat-file     # show object type or pretty-print its contents (e.g., -t, -p)
git ls-tree      # list a tree object
git write-tree   # write index to a tree object and print SHA
git commit-tree  # create a commit object from a tree SHA
git update-ref   # update a ref to point at a commit SHA
git rev-parse    # resolve revision names to SHAs

A quick plumbing example: create a commit without git commit

# 1. stage files
git add file1 file2

# 2. write a tree from the index
tree_sha=$(git write-tree)

# 3. create a commit pointing to that tree
commit_sha=\((echo "Commit created via plumbing" | git commit-tree \)tree_sha -p $(git rev-parse HEAD))

# 4. update a branch to point to the new commit
git update-ref refs/heads/tmp-branch $commit_sha

# inspect
git cat-file -p $commit_sha

Where objects live

Objects are stored under .git/objects/ using their SHA: the first two hex chars are a directory, the remaining chars are the filename. Each object is zlib-compressed and stores a header (type + size) followed by the raw content.

For example:

.git/objects/ab/cdef1234...  # object with sha ab cdef1234...

Why this model matters

• Snapshots, not diffs: every commit points to a full tree, which makes branching and switching cheap — Git simply points refs at different commits.

• Deduplication: identical file contents are stored once (blobs are content-addressed).

• Integrity: hashes provide tamper detection — changing an object changes its SHA and breaks references.

• Rewriting and recovery: because commits are immutable and linked, you can reason about parent-child relationships (and use tools like reflog to recover lost refs).

How this helps when things go wrong

• Merge conflicts: knowing commits are snapshots helps you reason about three-way merges — Git compares trees by their SHAs.

• Lost commits: if you lost a branch, git reflog and git fsck --lost-found can help locate dangling commits (their SHAs still exist until garbage collection).

• Rebase vs merge: rebase creates new commits with different SHAs (rewriting history); merge creates a commit with two parents.

Practical next steps

• Try the plumbing commands in a throwaway repository to see the raw objects.

• Use git cat-file -t <sha> and git cat-file -p <sha> to inspect objects.

• Read the "git internals" chapter of the Pro Git book for a deeper dive.

Conclusion

Git isn’t magic — it’s a simple, elegant content-addressable database built from blobs, trees, and commits. Once you internalize those primitives and a few plumbing commands, many mysterious behaviors become predictable and understandable.