Git Internals

Linus Torvalds described Git's core as "a stupid content tracker" — and that's the accurate mental model. Underneath the porcelain (add, commit, merge...) sits a tiny key-value database: the key is a SHA hash, the value is a compressed blob of bytes, and there are exactly four kinds of values (objects). Everything Git does — history, branching, diffing, merging — is built on top of that one primitive.

Unlike older centralized VCS tools (CVS, Subversion) that store a file's history as a chain of diffs/deltas, every Git commit points at a complete tree — the full state of every file, as it existed at that commit. git diff, git log -p, and friends compute differences on the fly by comparing two full snapshots; nothing is stored as a diff at the object level.

Every Git command can be understood as copying data between three places:

• Working directory — the plain files on disk you edit with a normal editor. Not part of the object database at all.
• Index / staging area — a snapshot-in-progress recorded in .git/index. What git commit will turn into a tree.
• Repository (object database + refs) — the immutable object graph plus the mutable pointers (branches, HEAD, tags) into it.

A tree entry can carry mode 160000 — a gitlink — whose "SHA" is a commit hash in an entirely different repository, not a blob/tree in this one. That's the whole mechanism behind submodules: the parent repo records exactly one pinned commit of the child repo, with no copy of its objects. git submodule update is what actually fetches and checks out that pinned commit into the working directory.

An object's ID is the hash of a small header plus its content: sha1("<type> <byte-length>\0" + content). The header means a blob containing exactly the same bytes as a commit object (astronomically unlikely, but conceptually) would still hash differently, because the header text differs. This is why identical file content always produces the identical blob SHA, regardless of filename, path, or which commit it's in — the hash only ever depends on the bytes.

$ echo -n "hello git internals" | git hash-object --stdin
19a3d3d4a52002ac7f7ef476ffc2ba1de1471ec9

$ echo -n "hello git internals" | git hash-object --stdin
19a3d3d4a52002ac7f7ef476ffc2ba1de1471ec9   # identical input → identical hash, every time

A freshly-created object is written as a loose object: zlib-deflate-compressed and stored at .git/objects/xx/yyyy…, where xx is the first two hex characters of its SHA (a directory, so no single directory ever needs millions of entries) and the rest is the filename.

Loose objects are simple but wasteful — one per object, no cross-object compression. Periodically (or explicitly via git gc), Git collapses many loose objects into a single .pack file plus a .idx index for O(log n) lookup by SHA prefix, using delta compression: similar objects (e.g. successive versions of one file) are stored as a small diff against a chosen base object rather than in full. Full detail in §8.

Porcelain commands (log, show, diff) are convenience wrappers. The plumbing commands underneath let you walk the exact same graph a commit points at:

$ git cat-file -p HEAD
tree 8f3d44b1c9e2a0f5b6d7c8a9b0e1f2a3b4c5d6e7
parent 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
author  David Veksler <[email protected]> 1782900000 -0700
committer David Veksler <[email protected]> 1782900000 -0700

Add README

$ git cat-file -p 8f3d44b1c9e2a0f5b6d7c8a9b0e1f2a3b4c5d6e7
100644 blob 3f2504e04f8964a875e69bfff8c5a4b8b5f2c1f3    README.md
100644 blob a1b2c3d4e5f60718293a4b5c6d7e8f9a0b1c2d3e    main.py
040000 tree 9d0e2f1a2b3c4d5e6f708192a3b4c5d6e7f80912    src

$ git cat-file -p 3f2504e04f8964a875e69bfff8c5a4b8b5f2c1f3
# Hello, Git

$ git cat-file -t 8f3d44b1c9e2a0f5b6d7c8a9b0e1f2a3b4c5d6e7
tree

Sample hashes above are illustrative; run this against your own repo to see the real graph.

Everything in .git/objects is content-addressed and immutable. Branches, HEAD, and tags are the opposite: small, deliberately mutable pointers that make the immutable graph usable as version control.

.git/index is a binary file: a header (signature, format version, entry count), then one sorted entry per staged path — mode, file size, mtime cache, and the blob SHA it would commit — followed by a checksum of the file itself. git add doesn't touch the object graph beyond writing a blob; it edits this one file.

The clearest way to internalize "porcelain is just choreography" is to do a commit's job yourself with plumbing:

$ echo "hello" > file.txt
$ BLOB=$(git hash-object -w file.txt)              # writes a blob object, prints its SHA
$ git update-index --add --cacheinfo 100644 $BLOB file.txt   # stage it (edit .git/index)
$ TREE=$(git write-tree)                             # index → tree object
$ COMMIT=$(git commit-tree $TREE -m "manual commit") # tree (+ parent, if any) → commit object
$ git update-ref refs/heads/main $COMMIT              # move the branch pointer — that's the "commit"

Four plumbing calls, one line of pointer-moving at the end. git commit is exactly this sequence, plus reading the previous HEAD as -p <parent> and appending a reflog entry.

Checking out a commit or tag directly (git checkout <sha>) puts a raw SHA into .git/HEAD instead of a branch reference. You can commit, build, and test normally — those new commits are entirely valid objects. The only real risk: since no branch ref points at them, switching away leaves them unreachable and eligible for garbage collection (§8) unless you first anchor them with git branch <name> or git switch -c <name>.

Each commit stores its parent(s) by hash, and a hash can only be computed after the thing it names already exists. A commit literally cannot reference a descendant, because that descendant's hash — which would have to include this commit as its parent — doesn't exist yet. The acyclic property isn't enforced by a rule Git checks; it falls directly out of hashing being one-directional in time.

When you run git merge feature from main, Git first walks the DAG backward from both tips to find their best common ancestor — in the diagram, that's B. It then diffs base→ours (B→C) and base→theirs (B→F), applies non-overlapping changes automatically, and flags anything both sides touched as a conflict. Inspect it yourself with git merge-base main feature.

If two branches have merged each other more than once, there can be multiple lowest common ancestors with no single "best" one. Git's default recursive/ort strategy handles this by first merging the candidate ancestors with each other to synthesize one virtual base, then doing the normal three-way merge against that. Most people never notice this machinery — until a merge conflicts in a spot that seems to have "nothing to do" with either branch's real changes, which is usually this case.

• HEAD~N — walk N steps back along first parents only. Meaningful for any commit, since it ignores side branches.
• HEAD^N — the Nth parent of a merge commit. Only meaningful at a merge (which is the only kind of commit with more than one parent); HEAD^1 = HEAD^ = HEAD~1.
• HEAD^2 on commit M above = F (the second parent, i.e. the branch that got merged in).

In every mode the commits you "reset away from" aren't deleted — they simply become unreachable from the branch ref, recoverable via the reflog (§8) until it expires or gc prunes them.

A commit object's bytes include the literal text of its parent SHA. Change the parent — even with the tree and message held perfectly identical — and the commit's own hash changes, because the input to the hash function changed. Every commit downstream references this commit's hash as its parent, so the change cascades through the entire remainder of the branch.

Git doesn't "choose" to fast-forward stylistically — it's forced whenever the target is a straight-line descendant of the current tip (no divergence to reconcile), and impossible otherwise. git merge --no-ff exists specifically to force a merge commit even when a fast-forward is possible, purely to keep a visible marker of "a branch merged here" in the graph.

Git never "deletes on undo." An object is kept as long as it's reachable — findable by walking parent/tree/blob pointers starting from some ref (a branch, tag, stash, or a reflog entry). Reset, rebase, branch deletion, and amend all just make certain commits unreachable from normal refs; the bytes remain on disk until an explicit collection pass decides otherwise.

• gc.auto = 6700 — once loose objects exceed roughly this count, ordinary commands opportunistically trigger git gc --auto to pack them.
• gc.autoPackLimit = 50 — once there are more than this many packs, they get consolidated into one.
• gc.pruneExpire = "2 weeks ago" — unreachable loose objects younger than this are kept (as a safety margin) even during an explicit gc.

Every time a ref (HEAD, a branch) moves on your machine, Git appends a line to that ref's reflog — a purely local, never-pushed journal of "where this pointer has been." It's the practical safety net under reset/rebase/amend: the old commit is still there, you just need its former reflog position.

• gc.reflogExpire = 90 days for entries still reachable some other way.
• gc.reflogExpireUnreachable = 30 days for entries that are not reachable from any current ref (the common case after --amend/rebase).

$ git reflog                      # find the entry just before the mistake, e.g. HEAD@{2}
$ git branch recovered HEAD@{2}  # anchor it to a real ref so it survives gc
# or, if you don't even remember a ref name — search every dangling object directly:
$ git fsck --no-reflogs --unreachable --full | grep commit
$ git show <dangling-sha>

Git has used a collision-detecting SHA-1 variant (hardened against the 2017 "SHAttered" attack) since 2017, so practical collision forgery against a Git repo isn't a live threat. A parallel SHA-256 object format exists (git init --object-format=sha256) and Git 2.51 marked it as the default hash for the planned Git 3.0 — but as of mid-2026, major hosting platforms (GitHub, GitLab) still don't support SHA-256 repositories, so the transition is gated on ecosystem support, not the Git client. SHA-1 and SHA-256 repos are designed to interoperate (a SHA-256 client can push/fetch to a SHA-1 server) once tooling catches up.

git clone --depth N fetches only the most recent N commits and synthesizes a "grafted" boundary — older parents genuinely don't exist locally. Anything that needs to walk past that boundary (full blame, some rebases, bisect across old history) fails or behaves oddly until git fetch --unshallow. --filter=blob:none (partial clone) takes the opposite approach: the full commit/tree graph is present, but blob content is fetched lazily on first access — different trade-off, same principle of deferring part of the object graph.

Signing a commit or tag (-S, GPG or SSH) signs the object's own canonical serialized bytes — tree/parent/author/message for a commit — everything except the signature field itself, which gets appended. It authenticates that exact snapshot and metadata, not "the diff the author intended"; git verify-commit / git log --show-signature re-derive the object and check the signature against it.

git worktree add ../hotfix hotfix-branch creates a second working directory + index, both pointed at the same .git/objects and refs as the original. It solves "I need two branches checked out simultaneously" without the disk/network cost of a second clone — a direct consequence of the working directory being just one of the three separate areas in §1.

git sparse-checkout set <patterns> (cone mode) restricts which paths get materialized into the working directory, while the index and full commit history remain complete. Useful on monorepos where checking out every path would be prohibitively slow — the object graph is unaffected, only what gets written to disk for you to see.