<aside> 🔀
Module 9 — Collaboration Workflows (pull requests, forks, Git Flow). Git gives a team mechanics; a workflow gives it manners. This module covers the human layer built on Modules 5–8: feature branches, pull requests and review, forks, and the branching-model debate (Git Flow vs GitHub Flow vs trunk-based) that every team — and many interviews — eventually litigates. Almost nothing here is a new Git command; everything here is how teams arrange the commands you already know.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 8 completed, with the bakery.git bare remote and both clones (kitchen, kitchen-laptop2) on disk — the exercises simulate a full team flow against them, offline. Concepts assumed fresh: --no-ff merges and three-dot diffs (Module 6), upstream tracking and multi-remote setups (Module 8).
</aside>
<aside> 📖
Official docs: Git Book §3.4 — Branching Workflows · GitHub flow
</aside>
Underneath every named methodology sits one shared skeleton: main is sacred, work happens on branches. main must always be releasable — nobody commits to it directly; it moves only by merging reviewed branches. Each unit of work (feature, fix, experiment) gets its own short-lived branch, named descriptively (feature/PAY-231-refund-retry — Module 5's convention capstone), pushed early so it is visible and backed up, merged when reviewed, deleted when merged. The cycle you are about to run is, with a web UI on top, the daily loop of most software teams on earth.
🧪 Exercise 9.1 — a feature's whole life, part one: branch, work, publish
cd ~/git-course/kitchen # on main
git switch -c feature/holiday-menu
echo "stollen: december only" > stollen.txt
git add stollen.txt && git commit -m "Add stollen to holiday menu"
git push -u origin feature/holiday-menu
<aside> 📖
Official docs: Git Book §3.2 — Basic Branching and Merging
</aside>
While your branch lives, main receives other people's merges. The longer you drift from it, the bigger the eventual conflict (Module 6's fleet lesson). The standard hygiene: periodically merge main into your feature branch — the same git merge, pointed the other way. Conflicts, if any, get resolved on your branch, at your pace, leaving main pristine — and the final merge back becomes trivial because you already did the hard part. (Rebasing the branch instead is the tidier alternative many teams prefer — Module 10 adds it; the merge version below is always correct.)
🧪 Exercise 9.2 — main moves; you catch up
cd ~/git-course/kitchen # simulate the team: land something on main
git switch main
echo "gingerbread: december only" > gingerbread.txt
git add gingerbread.txt && git commit -q -m "Add gingerbread note" && git push -q
git switch feature/holiday-menu # back on your feature
git merge main --no-edit # bring main's progress IN
git log --oneline -3