Quiz
Warm-up from lesson 2-2. You edit soup.txt and run git add soup.txt. Where does the change now live?
git restore has two jobs
Mistakes are half of programming: an experiment that made a file worse, a git add . that staged junk. Without a targeted undo you would be hand-editing files back to how you remember them — exactly the manual-versioning misery from lesson 1-1. git restore is the everyday undo for work that hasn't been committed yet, and it exists in two flavors because there are two places uncommitted work lives (lesson 2-2): the working directory and the staging area.
Job 1: throw away working-directory edits.
$ git restore pancakes.txt
This replaces your edited pancakes.txt with the version from the staging area (or, if nothing is staged, the last commit). Your recent edits are gone, permanently. Git can't recover changes it was never given, so treat plain restore as the one genuinely dangerous everyday command. Use it when you've made a mess and truly want out.
Job 2: unstage, with --staged.
$ git restore --staged pancakes.txt
This is the opposite of git add. The file leaves the staging area, but your edits stay safely in the working directory. Completely harmless.
You never have to memorize these cold: git status literally prints both commands as hints next to the files they apply to.
You ran git add . and accidentally staged debug-notes.txt along with real work. Get it out of the next commit without losing the file.
Step 1/3: See the situation.
Quiz
Which command can permanently destroy work you haven't committed?
Quiz
You ran git add . and accidentally staged debug-notes.txt along with real work. You want it out of the next commit but you don't want to lose the file's contents. What do you run?
Problem
Fill in the blank to unstage a file without touching its contents: git restore ___ recipe.txt