<aside> 🔀
Module 5 — Branching (git branch, switch, checkout). Branches are why Git won. They make parallel lines of work — a feature, a hotfix, an experiment — cost nothing to start and nothing to abandon. And because of Module 3, you already know the secret: a branch is a 41-byte file. This module makes that fact into daily practice, and defuses Git's most famous scare, the detached HEAD.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 3 (refs, HEAD, the object graph) and Module 4 (log --oneline, --graph, revision names). The exercises continue in the kitchen repository, including Module 3's Exercise 3.7 commit. Tools: just Git and a terminal.
</aside>
<aside> 🖼️
This page contains Mermaid diagram blocks. Notion shows them as code by default — click the block and switch it to Preview to see the diagram. You only need to do this once per block.
</aside>
<aside> 📖
Official docs: Git Book §3.1 — Branches in a Nutshell · git-branch manual
</aside>
Module 3, Exercise 3.6: main is a text file holding one commit hash, and committing overwrites it with the new hash. That is the complete definition — a branch is a named, movable pointer to a commit. Creating a branch (git branch <name>) writes one more 41-byte file pointing at the same commit you are on. No files are copied, no "branch folder" exists, nothing about your project changes. Two names now reference one commit; history is still one chain. The pointers only begin to differ when commits start moving them (Part B).
git branch with no arguments lists your branches, with * marking the one HEAD names; git branch -v adds each pointer's current commit — worth preferring, because it displays exactly the mental model: names → hashes.
🧪 Exercise 5.1 — create a branch and prove how cheap it was
cd ~/git-course/kitchen
git branch sourdough # create; do NOT switch to it yet
git branch -v # both names, and where each points
cat .git/refs/heads/sourdough
cat .git/refs/heads/main # compare the two files
<aside> 🔖
Real-world analogy — two bookmarks in one book
A branch is a bookmark. Putting a second bookmark at the page you are reading costs nothing and copies no pages — the book does not know or care. Each reader's progress is just "which page their bookmark is on," and moving a bookmark never changes the text. Ten bookmarks, one book.
Where the analogy stops working. Two readers of one book share the same fixed pages forever. Git's "readers" write: from the shared page onward, each branch can add its own new pages, and the book becomes a choose-your-own-adventure — one spine of shared history that forks into different continuations (B2 shows the fork happen). No physical book grows different endings depending on which bookmark you carried; Git's does, and merging those endings back together is Module 6's whole subject.
</aside>
<aside> 📖
Official docs: Git Book §3.1 — Branches in a Nutshell
</aside>
In older VCSs (Module 1's SVN), a branch was a server-side directory copy — heavyweight enough that teams branched rarely and dreaded it. Git's pointer design inverts the economics: creating, switching, and deleting branches are constant-time pointer operations, so the workflow changes shape. Risky refactor? Branch. Quick experiment? Branch. Production hotfix while mid-feature? Branch. Abandon an idea by deleting its pointer — the 41 bytes are gone and (eventually) its unreferenced commits are garbage-collected, with no ceremony. Every collaboration model in Module 9 is built on the assumption that branches are free; this section is where that assumption becomes intuition.
flowchart RL
M["main"] --> C3["commit cff4379"]
S["sourdough"] --> C3
H["HEAD"] -.->|"ref:"| M
C3 --> C2["commit 04776eb"]
C2 --> C1["...older commits"]