05 · Git & Version Control
Phase: 2 · Estimate: 1 week · Prerequisites: none
Why it matters
Almost every developer can commit and push, but panics at a rebase conflict, a detached HEAD, or a "lost" commit. Once you understand Git's object model, no command feels scary anymore.
Concept map
Basics
-
init,add,commit,status,log,diff - Branches, merging, conflict resolution
- Remotes:
clone,fetch,pull,push - VCS hosting: GitHub, GitLab, Bitbucket; pull requests / merge requests
Intermediate
-
rebasevsmerge, interactive rebase,--fixup+--autosquash -
reset(soft/mixed/hard) vsrevertvsrestore -
reflogto rescue "lost" commits -
stash,cherry-pick,bisect - Conventions: Conventional Commits, trunk-based vs Git Flow
Deep dive
- The object model: blob, tree, commit, tag; content-addressable storage
- Refs, HEAD, and the index (staging area) as files
- Packfiles and delta compression
- Merge strategies (
ort) and three-way merges
How to learn
- Create an empty repo, then run
find .git -type fafter each command to see what changed. - Use
git cat-file -p <hash>to walk commit → tree → blob by hand. - Practice
bisecton a repo with a bug planted in commit 37 of 50. - Rescue a commit after
reset --hardusingreflog.
Check your understanding
- What does a commit actually store? Why does changing one file change the hash of every later commit during a rebase?
- Why is "don't rebase a shared branch that's already been pushed" a sensible rule?
- What's the difference between
git reset --soft HEAD~1andgit revert HEAD? - How does Git know a file was renamed when it only stores snapshots?
Practice projects
| Level | Project | What it trains |
|---|---|---|
| Basic | Contribute a PR to an open source repo (docs count) | PR workflow |
| Intermediate | Set up a repo with Conventional Commits + commitlint + an automatic changelog | Conventions, tooling |
| Deep | Write a mini Git: init, hash-object, cat-file, write-tree, commit-tree | Object model |
Primary sources
Related toolkit
- This repo itself uses changesets to version its packages