<aside> 🔀
Module 6 — Merging (git merge, merge conflicts). Branching split your history in two; merging is the reunion. It is also the moment beginners fear most, because of conflicts. This module removes the fear the only way that works: by showing the mechanism. A merge is a computation over three snapshots — once you can name the three, every merge behavior (including conflicts) becomes predictable.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 5 completed, with the kitchen repository in its end state: main (with the rye commit) and sourdough (with the starter commit) diverged from a common ancestor, and sourdough not yet merged or deleted. 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.2 — Basic Branching and Merging · git-merge manual
</aside>
git merge <branch> means: bring that branch's work into the branch I am on. To do it, Git locates three snapshots: ours — the tip of the current branch; theirs — the tip of the branch being merged; and the merge base — the common ancestor you spotted in Module 5's graph, the last commit both sides share. git merge-base A B prints it any time. The base is what makes merging computation rather than guesswork: comparing each side against the base tells Git exactly what each branch changed — and "what changed on each side since we parted" is precisely the information needed to combine them.
One vocabulary note before the exercises: merging happens into the branch you are on. git merge sourdough while on main changes main only — sourdough is read, not written. Getting this direction backwards is the most common merge mistake in real teams.
<aside> 📖
Official docs: git-merge manual
</aside>
Special case first. If the branch being merged is strictly ahead — your current tip is the merge base, because nothing was committed on your side since the fork — then there is nothing to combine. The other branch's history already contains yours. Git just slides your branch pointer forward to their tip: a fast-forward. No new commit, no combination, a pure Module 3 pointer move. This is exactly the main/sourdough shape before Module 5's rye commit — and it is the everyday case when you finish a small feature branch nobody else raced against.
🧪 Exercise 6.1 — a fast-forward, end to end
cd ~/git-course/kitchen # on main
git switch -c glaze # branch, add one commit...
echo "brush with milk for shine" > glaze.txt
git add glaze.txt && git commit -m "Add milk glaze note"
git switch main # ...and merge it back immediately
git merge glaze
git branch -d glaze # merged: -d is now happy (Module 5's seatbelt)
<aside> 🛣️
Real-world analogy — catching up vs merging traffic
Two cars leave a junction. If your car never moved, "merging" with the car ahead just means driving forward along the road it already traveled — you fast-forward over its route; no maneuvering needed, because there is only one route. But if both cars drove different roads, rejoining requires a real junction: somebody has to interleave the two paths into one, and that junction is a real place on the map afterwards (the merge commit, Part B).
Where the analogy stops working. Cars merge in real time and the maneuver leaves no trace. Git's junction is recorded: the merge commit permanently holds pointers to both roads, so anyone later can see exactly which two lines of work met, when, and what each contributed. History is not just reunited — the reunion itself becomes history. That permanence is why teams sometimes force a junction to exist even when fast-forwarding was possible (--no-ff, Part D).
</aside>