Reading — step 1 of 5
Read
~1 min readBranching, Diff & Merge
Putting It All Together
You now have all the moving parts:
| Layer | What you built |
|---|---|
| Hashing | hash-object — content-addressable IDs |
| Storage | Inflate/deflate object format |
| Trees | Sorted entries with binary SHAs |
| Commits | Tree + parents + author + message, hash-pinned |
| Walks | BFS over commit graph, ordered |
| Refs | Branches, tags, HEAD as symbolic or detached |
| Index | The "next commit" snapshot |
| Status | HEAD vs Index vs Work, three-way comparison |
| Checkout | Tree -> file write/remove plan |
| Diff | LCS-based line edit script |
| Merge | Three-way per-file (BASE / OURS / THEIRS) |
The full git CLI sits on top of these primitives. Plumbing commands map
1:1: git hash-object, git cat-file, git ls-tree, git update-ref,
git read-tree, git write-tree, git commit-tree. Porcelain commands
(git add, git commit, git checkout, git merge) are convenience
layers over the plumbing.
What we glossed over:
- Packfiles — efficient storage of millions of objects via delta chains
- The smart protocol —
git fetch/git pushover HTTP / SSH - Hooks — pre-commit, post-merge, pre-push scripts
- Stash — saves working tree as commits on a special ref
- Bisect — binary search for the bad commit
- Worktrees — multiple checkouts of the same repo
- submodules — embedded repos pinned by SHA
- LFS — large-file storage outside object DB
- The reflog — local history of HEAD/branch movements (recovery!)
But these are all built on the same five primitives: blobs, trees, commits, refs, and SHA-1. You now understand what makes Linus's design so elegant — and why every other VCS that came after has tried to copy it.
Discussion
Ask a question, share an insight, or help someone who’s stuck.
Sign in to post a comment or reply.
Loading…