<aside> 🔀
Module 7 — Undoing Work (git reset, revert, restore, reflog). Everyone breaks things; professionals undo them calmly. Git has four undo tools, and they are not interchangeable: restore (uncommitted files), reset (move the branch itself), revert (undo by adding history), and the reflog (find anything you thought was gone). Choosing correctly between them — especially once work is shared — is one of the most-asked interview topics in this entire track.
🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start. You need Module 6 completed — the exercises continue the kitchen repository from its end state (the seeds merge commit exists), and Part D reverts that very merge. You also need the three-trees model (Module 2) and refs/HEAD (Module 3) fresh in mind. 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-restore manual · Git Book §2.4 — Undoing Things
</aside>
git restore <file> overwrites the working-tree file with the copy in the index — "make it look like it did the last time I staged or committed it." You have seen git status advertise it since Module 2 (use "git restore <file>..." to discard changes). One property makes it different from nearly everything else in this module: the edits it discards were never committed and never staged, so they exist in no object anywhere — this is the one Git command in daily use that destroys work unrecoverably. Treat the command like rm: read the filename twice.
🧪 Exercise 7.1 — ruin a file, restore it
cd ~/git-course/kitchen # on main, clean, post-Module 6
echo "RUINED" > method.txt # simulate a bad edit / fat-fingered redirect
git status -s
git restore method.txt
cat method.txt
git status -s # prints nothing: clean again
<aside> 📖
Official docs: git-restore manual
</aside>
git restore --staged <file> is the opposite direction of git add: it copies the HEAD version of the file's entry back into the index, un-staging your change — while leaving the working-tree file untouched. Nothing is lost; the change simply exits the next-commit draft. (Status has been advertising this one too: use "git restore --staged <file>..." to unstage.) The two flags compose: git restore --staged --worktree <file> does both at once, and --source <commit> restores from any commit instead of the default — the write-flavored sibling of Module 4's read-only git show <commit>:<file>.
🧪 Exercise 7.2 — stage, change your mind, unstage
cd ~/git-course/kitchen
echo "cool on wire rack" > cooling.txt
git add cooling.txt
git status -s # staged new file
git restore --staged cooling.txt
git status -s # file untouched, no longer staged
rm cooling.txt # tidy up: we decided against it entirely