How Git Thinks – Snapshots, the DAG, and SHA-1 Hashes

Snapshots, Not Diffs

The most fundamental thing to understand about Git is how it stores data. Most older version control systems (CVS, SVN, Perforce) think of history as a list of file-based changes — they store the initial version of each file, then record only the lines that changed in each subsequent version.

Git is completely different. Git thinks of its data as a series of snapshots of your entire project. Every time you commit, Git takes a picture of all your tracked files at that exact moment and stores a reference to that complete snapshot. If a file has not changed since the last commit, Git does not store it again — it simply stores a reference (pointer) to the identical file it stored previously. This is both storage-efficient and conceptually simple: each commit is a complete, self-contained state of your project.

This snapshot model is why Git operations like branching, merging, and switching between commits are so fast. Git never needs to "reconstruct" a file version by replaying diffs — it just retrieves the snapshot directly.

The Three Areas

Every file in a Git repository exists in one of three distinct areas. Moving files between these areas is what the core Git commands actually do. Getting this model clear in your head removes 80% of the confusion beginners experience with Git.

# Working Tree → Staging Area
# "git add" copies files from your working tree into the staging area
git add index.html

# Staging Area → Repository
# "git commit" takes everything in the staging area and saves a snapshot
git commit -m "Add homepage"

# Repository → Working Tree
# "git checkout" or "git restore" copies files from a commit back to your working tree
git restore index.html

The staging area is the most misunderstood area for beginners. Why does it exist? It gives you fine-grained control over what goes into each commit. If you changed 10 files but only want to commit 3 of them together (because they are logically related), you stage just those 3. The other 7 remain modified in your working tree, ready to be staged in a future commit. This produces a clean, meaningful commit history — which is one of Git's most valuable professional features.

The Commit DAG

Commits in Git do not form a simple linear list — they form a Directed Acyclic Graph (DAG). Each commit stores a reference to its parent commit (or two parent commits in the case of a merge). This chain of parent references is what makes Git's history work.

"Directed" means the arrows in the graph point in one direction (each commit points to its parent, backwards in time). "Acyclic" means the graph has no cycles — you can never follow parent references and end up back at the same commit.

# View the commit graph as a visual tree (very useful!)
git log --oneline --graph --all

When you create a branch and make commits on it, and then merge it back, Git creates a merge commit that has two parents — one from each branch. This is what the |\ and |/ in the graph above represents. The DAG structure is what makes Git's powerful merge and rebase operations possible.

SHA-1 Hashes — Git's Unique IDs

Every single object in Git — every commit, every file version, every directory snapshot — is identified by a SHA-1 hash: a 40-character hexadecimal string like a1b2c3d4e5f6789012345678901234567890abcd. This hash is computed from the content of the object.

This content-based addressing has profound implications:

• Integrity — If any bit of a file or commit is corrupted, its hash changes, and Git detects the corruption immediately.
• Deduplication — Identical content always produces the identical hash, so Git stores duplicate content exactly once.
• Immutability — You cannot change a past commit without changing its hash (and all subsequent commits). Git history is tamper-evident.

# See full commit hashes in the log
git log

# See abbreviated (short) hashes — first 7 characters
git log --oneline

# You can reference a commit by its first 4-7 characters
# as long as they are unique in the repository
git show a1b2c3d

# Git tells you the hash of the current commit
git rev-parse HEAD

HEAD — Where You Are Right Now

In Git, HEAD is a special pointer that tells you where you currently are in the repository. Most of the time, HEAD points to a branch name, which in turn points to the latest commit on that branch. When you make a new commit, the branch moves forward to the new commit — and HEAD moves with it, always pointing to the branch tip.

# See what HEAD is pointing at
cat .git/HEAD
# Output: ref: refs/heads/main

# After switching branches, HEAD updates
git switch feature/login
cat .git/HEAD
# Output: ref: refs/heads/feature/login

# "Detached HEAD" — HEAD points directly to a commit hash, not a branch
git checkout a1b2c3d
cat .git/HEAD
# Output: a1b2c3d4e5f6789012345678901234567890abcd

The concept of detached HEAD confuses many beginners. It simply means HEAD is pointing directly at a commit instead of at a branch. You are "looking at" that specific commit. If you make commits in this state, they have no branch pointing to them and will be garbage-collected eventually. To keep those commits, create a new branch: git switch -c new-branch-name.

Git's Four Object Types

Git's object database stores exactly four types of objects. Understanding these types gives you a complete picture of how Git represents your project:

When you run git commit, Git creates a new commit object that references a tree object (the root of your project directory), which in turn references blob objects for each tracked file. The commit object also records its parent commit's hash, forming the chain. This is the entire storage model — everything in Git is built from these four object types.