How Git Works Internally

Reviewed & published by Brayan K

Under its commands, Git is a tiny content-addressable database of four object types — blobs, trees, commits, and tags — every one keyed by a hash. Once you see the object model, refs, HEAD, and the commit DAG, everything else (amend, rebase, why commits are immutable) suddenly makes sense. This lesson opens the hood.

Part of the free Git course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• The four objects: blobs, trees, commits, tags
• Content-addressable storage keyed by a hash
• Explore .git/objects with cat-file and hash-object
• Refs and HEAD as pointers to commits
• The commit DAG and parent links
• Why commits are immutable snapshots

1️⃣ The Object Model

Everything in Git is one of four objects, each keyed by a hash. A blob is the bytes of one file; a tree is a directory mapping names to blobs and sub-trees; a commit is a snapshot pointing at a root tree plus parent(s), author, and message; a tag is an annotated pointer to (usually) a commit. A commit points to a tree, which points to blobs.

# Git's whole database is just four kinds of object, each keyed by a hash.
#
#   BLOB    -> the raw bytes of ONE file (no name, no metadata)
#   TREE    -> a directory: names + modes pointing at blobs and sub-trees
#   COMMIT  -> a snapshot: one root tree + parent(s) + author + message
#   TAG     -> a named, annotated pointer to another object (usually a commit)
#
# A commit points to a tree; a tree points to blobs and more trees:
#
#   commit --> tree --> blob   (README.md)
#                  \--> tree --> blob   (src/app.js)
#
# Everything is content-addressable: the id IS the hash of the content.

2️⃣ Content-Addressable Storage

Git stores objects under a hash of their content (SHA-1, or SHA-256 in newer repos), in .git/objects. git hash-object shows the id Git would give content, and git cat-file -p pretty-prints any object. Identical content always hashes the same — that's how Git deduplicates.

# Prove that Git ids are hashes of content. Hash a string yourself:
echo "hello git" | git hash-object --stdin
#   -> 8d0e41234f24b6da002d962a26c2495ea16a425f

# Identical content always hashes to the SAME id (that's deduplication).
# Now look inside the real object store of a repo:
ls .git/objects                # subdirs named by the first 2 hash chars

# Pretty-print ANY object by its id with cat-file:
git cat-file -p HEAD           # shows the commit object

3️⃣ Refs, HEAD & the Commit DAG

Branches and HEAD are just refs — small files holding a commit id. A branch ref under .git/refs/heads points to a commit; HEAD usually points to the current branch. Because each commit records its parent, commits form a Directed Acyclic Graph (DAG): the shape of your history.

# Branches and HEAD are just POINTERS (refs) — plain files holding a hash.

# A branch ref is literally a file containing one commit id:
cat .git/refs/heads/main
#   9b1d4e0a7c3f2e1d8b6a5c4f3e2d1c0b9a8f7e6d

# HEAD usually points at the CURRENT branch, not a commit directly:
cat .git/HEAD
#   ref: refs/heads/main

# So: HEAD -> branch ref -> commit -> tree -> blobs. Each commit also
# records its PARENT, forming a Directed Acyclic Graph (DAG) of history.

4️⃣ Why Commits Are Immutable

A commit's id is a hash of its content — tree, parent(s), author, message. Change one byte of a file and the blob hash changes, so the tree hash changes, so the commit hash changes. The old commit still exists, untouched, with its original id. Nothing is edited in place — which is precisely why amend and rebase create new commits.

# Commits are IMMUTABLE because the id is derived from the content.
# Change one byte of a file and EVERYTHING downstream gets a new id:

# 1) Inspect the tree a commit points to
git cat-file -p HEAD^{tree}

# 2) Edit a file, commit again — the blob hash changes, so the tree hash
#    changes, so the commit hash changes. The old commit still exists,
#    untouched, with its original id. Nothing was edited in place:
git log --oneline -2

# That's why "amend" and "rebase" create NEW commits rather than editing.

Your turn. Walk from HEAD down toward a file's bytes and hash content yourself. Fill in the two blanks.

# 🎯 YOUR TURN — replace each ___ then run it in your terminal.
# Goal: walk the object graph by hand, from HEAD down to a file's bytes.

# 1) Pretty-print the current commit to see its tree + parent + message
git ___ -p HEAD                 # 👉 the command that prints any object

# 2) Hash a piece of content yourself to see Git's content-addressing
echo "demo" | git ___ --stdin   # 👉 the command that computes an object id

# 3) Show the branch ref is just a file holding a commit id
cat .git/refs/heads/main

# ✅ Expected: step 1 shows a commit with a tree line and a parent line;
#    step 2 prints a 40-char hash; step 3 prints that same kind of hash.

Common Misconceptions (and the truth)

• "A commit stores diffs": no — a commit references a tree that is a full snapshot. Diffs are computed between commits on demand.
• "A blob knows its filename": it doesn't. The name lives in the tree entry that points to the blob.
• "Amend edits a commit in place": it can't — a new id means a new object. The old commit still exists until garbage-collected.
• "A branch is a copy of files": a branch is just a ref — one file holding a commit id, nothing more.

Pro Tips

• 💡 cat-file -t tells the type: use git cat-file -t <hash> to see if an id is a blob, tree, or commit.
• 💡 Trees are snapshots: remembering that explains why history is cheap and branching is instant.
• 💡 Hashes mean integrity: any corruption changes the hash, so Git can detect it.
• 💡 Reflog saves you: even "lost" commits exist by id until garbage collection runs.

📋 Quick Reference

Mini-Challenge: Trace the Graph

No commands given this time — just the plan. Walk from a commit all the way down to raw file bytes.

🎉 Lesson Complete!

• ✅ Git's database is four objects: blobs, trees, commits, tags
• ✅ Storage is content-addressable — the id is a hash (SHA-1 or SHA-256) of the content
• ✅ git cat-file -p and git hash-object let you explore .git/objects
• ✅ Branches and HEAD are refs; commits link to parents, forming a DAG
• ✅ Commits are immutable snapshots — change anything and you get a new id
• ✅ That's the Git course complete — you now understand Git from commands to internals

Practice quiz

Continue this course

• Previous: Git LFS & Large Files
• Quick reference: Git cheat sheet

Frequently asked questions

What are the four object types in Git?

Git's database is built from four object types, each addressed by a hash. A blob stores the raw contents of a single file (no name, no metadata). A tree represents a directory, mapping names to blobs (files) and other trees (subdirectories). A commit captures a full snapshot — it points to one root tree, references its parent commit(s), and records author/committer info and a message. A tag is an annotated, named pointer to another object, usually a commit. Together these form the entire history.

What does it mean that Git is content-addressable?

It means an object's identity is the hash of its content, not a name you assign. Git runs the object's bytes through SHA-1 (or SHA-256 in newer repositories) and stores it under that hash in .git/objects. A powerful consequence is deduplication: two identical files anywhere in history produce the same blob id and are stored once. It also means you can't change an object without changing its id — content and identity are inseparable.

How do I look inside Git objects myself?

Two commands open the hood. git cat-file -p <hash> pretty-prints any object, so you can read a commit's tree/parent/message, list a tree's entries, or dump a blob's bytes. git hash-object computes the id Git would assign to a piece of content (and with -w writes it into the store). Combined with browsing .git/objects, these let you trace a commit down to a tree and then to the raw file content of a blob.

What are refs, branches, and HEAD really?

A ref is just a pointer: a small file under .git/refs holding a commit id. A branch is a ref under refs/heads that moves forward as you commit. HEAD is normally a symbolic ref naming your current branch, so following HEAD leads to a branch, which leads to a commit, whose tree leads to blobs. Because each commit also records its parent(s), the commits form a Directed Acyclic Graph (DAG) — the shape of your project's history.

Why are commits immutable?

Because a commit's id is a hash of its content — its tree, its parent(s), the author and committer details, and the message. Change any of those, even one byte of one file, and the blob hash changes, which changes the tree hash, which changes the commit hash. You don't get an edited commit; you get a brand-new object with a new id, while the original still exists untouched. This is exactly why operations like amend and rebase create new commits rather than modifying old ones in place.

Related lessons

• Amending Commits
• Rebasing