<aside> 🔀
Module 11 — Stash and Worktrees (git stash, worktree). The Advanced tier opens with two tools for one problem: an interruption arrives while your work is half-done. git stash parks messy work in seconds and gives you a clean tree; git worktree lets you check out a second branch in a second directory so you never have to park at all. Module 5's hotfix ticket — "fix production while mid-feature" — finally gets its two clean solutions.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 5 (branches, switching, the one-working-tree fact), Module 6 (conflicts — stash can conflict), and Module 3 (a stash is secretly commits). A fresh kitchen repo with a sourdough branch works; the exercises are self-contained and rebuild what they need.
</aside>
<aside> 📖
Official docs: git-stash manual · Git Book §7.3 — Stashing and Cleaning
</aside>
git stash takes your uncommitted changes — modified tracked files and the staged index — records them somewhere safe, and resets your working tree to a clean HEAD. You get an instant clean slate without committing half-finished work. The changes go onto a stack (git stash list), so you can stash several times and retrieve them later. Two everyday retrievals: git stash pop reapplies the most recent stash and removes it from the stack; git stash apply reapplies but leaves it on the stack for reuse. One catch to meet head-on: by default stash ignores untracked files (Git will not touch files it does not track), so a brand-new file is left sitting in your "clean" tree — the -u flag (A3) includes them.
🧪 Exercise 11.1 — stash, get a clean tree, then pop it back
cd ~/git-course/kitchen # on main, clean
echo "experimental: add honey to bread" >> bread.txt # modify a tracked file
echo "scratch idea" > ideas.txt # and create an untracked one
git status -s
git stash
git status -s # what got parked, what didn't?
git stash list
🧪 Exercise 11.2 — pop brings it back and clears the stack
cd ~/git-course/kitchen
git stash pop
git status -s
git stash list # empty now
<aside> 🧥
Real-world analogy — the coat check
You walk into a restaurant carrying bags (your uncommitted work) and need your hands free (a clean tree) to shake someone's hand. The coat check takes your things, hands you a numbered ticket (stash@{0}), and holds everything until you come back. pop is redeeming the ticket and walking out with your bags; apply is looking at your bags but leaving them checked for now.
Where the analogy stops working. A coat check holds your things exactly as given and hands them back unchanged. A stash reapplies onto whatever the tree looks like now — if the room rearranged while your coat was checked (the branch moved, files changed), reapplying is a three-way merge that can conflict (A2's exercise). Your "coat" isn't returned to an empty rack; it's re-draped over a room that may have changed shape.
</aside>
<aside> 📖
Official docs: git-stash manual
</aside>
Stash's headline use is Module 5's hotfix scenario: mid-feature, park with git stash, switch to a clean branch, do the urgent work, switch back, git stash pop. Because a stash is not tied to a branch, you can even pop it onto a different branch — deliberately moving work you started in the wrong place. But reapplying is a merge (the analogy's punchline), so if the target's content diverged from where you stashed, pop conflicts — same markers, same resolution as Module 6, with one mercy: a conflicting pop keeps the stash rather than dropping it, so a botched reapply loses nothing.
🧪 Exercise 11.3 — force a conflicting pop, and see the stash survive
cd ~/git-course/kitchen # ensure clean: git checkout -- . ; rm -f ideas.txt
echo "honey version" >> bread.txt
git stash # park the honey change
echo "butter version" >> bread.txt # the same line now changes differently...
git commit -qa -m "Add butter to bread"
git stash pop # ...so reapplying the honey change collides
echo "exit code: $?"
git stash list # still there!