Engineer's toolkit
Git internals and workflow
Git as a content-addressed object store plus a graph of commits and movable pointers, so merges, rebases, bisects and recoveries stop feeling risky, along with the team workflows that go with them.
Most engineers learn Git as a list of commands: add, commit, push, plus a search engine for everything else. That works until a rebase goes wrong, a force-push erases a teammate's work, or someone types git reset --hard. Then the command list stops helping, because it does not say what Git is.
Git is simpler underneath. It is a content-addressed object store, a key-value store where each key is the hash of its value. It holds four kinds of objects, plus a few refs, which are named pointers into a graph of commits. Every command, from merge to cherry-pick to rebase -i, creates objects or moves pointers.
Two consequences follow. Almost nothing is truly lost. And most "disasters" are undone by moving a pointer back.
Concepts in this section
Read them in order. The first two explain the model. The rest use it.
| Step | Concept | What it answers |
|---|---|---|
| 1 | Git's object store | What does Git actually store, and why are IDs hashes? |
| 2 | Refs, HEAD and the reflog | What is a branch, and how do I get a lost commit back? |
| 3 | Merge, rebase and squash | What does each way of combining branches produce? |
| 4 | Editing history and recovering work | How do I clean up commits, and undo a bad move? |
| 5 | Bisect regressions | How do I find the commit that broke something? |
| 6 | Team workflows | Trunk or GitFlow, small PRs, and monorepo or polyrepo? |
Common mistakes
- Treating commands as a memorized list. Learn the model, and the commands follow.
- Rewriting shared history. Rebasing commits others have built on forces everyone to untangle duplicates.
- Panicking after a bad reset or rebase. The old commits are usually still there. Check the reflog first.
- Keeping work only in the working directory. Uncommitted changes that get overwritten cannot be recovered. Commit early, then squash later.
Key takeaways
- Git stores four object types (blob, tree, commit, tag) by content hash. History is a graph of hashes, so changing one byte changes every hash after it.
- A branch is a file containing a commit hash. Creating one is instant.
- The reflog records pointer moves for about 30 to 90 days, which makes most mistakes reversible.
- Merge preserves history, rebase rewrites it into a line, and squash collapses a branch into one commit. Never rebase shared commits.
- Small PRs and trunk-based development keep Git work calm, and
git bisectfinds regressions in about log2(N) steps.
Further learning
MIT's Missing Semester lecture builds Git from its data model up, the same approach as this section, with live demos.
Pro Git: Git Internals, Plumbing and Porcelain is the reference for the object model.
The Missing Semester of Your CS Education (MIT) covers the wider set of tools around Git.
Related
Code review
Author small, reviewable PRs and give reviews that improve both the code and the author — design first, tone that teaches, turnaround that unblocks.
Continuous integration and the software supply chain
Fast, trustworthy pipelines - build, test, artifact, scan and sign - plus DORA metrics and supply-chain controls that keep trunk green.
Debugging
A scientific loop for finding bugs fast — reproduce, hypothesize, bisect, instrument — from local failures to production incidents without making things worse.