The three areas
One file, two kinds of change, and only one of them is supposed to leave the building today.
You found it — the mobile nav bug. On phones under 480px, the menu button was invisible because of one wrong CSS class in index.html. Real fix, three lines, clean. While you were in there hunting for it, you also dropped in two console.log() lines to watch a variable while you debugged. Both changes are sitting in the same file, unsaved to history, right now.
Rachit leans over: "Anvesha's doing a quick review of the nav fix at 5 — can you commit it before then?"
You go to commit. And you realize: index.html is just "modified" as far as Git's concerned. There's no way to tell it "these three lines, not those two" — or is there?
The packing-table problem
Picture how the club actually preps merch orders before a workshop. There's a table with all the loose stock — T-shirts, stickers, lanyards — that's the equivalent of your working directory: everything as it currently sits, edited or not, ready or not. Before anything ships, someone portions out exactly what's going in today's box: two shirts, one sticker, no lanyard. That portioned pile, set aside but not yet sealed, is the staging area. Only once the box is taped shut — the commit — does that exact portioned set become a permanent, shippable record.
The reason this three-step process exists instead of just "seal whatever's on the table" is exactly your situation right now. The table has both the nav fix and the debug logs on it. You don't want to seal a box with debug logs in it. So you don't portion the whole table — you portion just the lines you want.
nav fix + 2 console.logs
nav fix only
a clean, honest commit
Portioning one file into two piles
git add -p — "patch mode" — walks you through your changes one small chunk ("hunk") at a time and asks, for each one, whether it belongs in the box:
y puts that hunk on the portioned pile. n leaves it on the table. The nav fix is now staged; the debug logs are still sitting, unstaged, in the same physical file on your disk — Git is tracking two different versions of one file at once, and that's exactly the trick that solves your 4:40 problem.
5:00 PM. Anvesha reviews a commit that contains exactly the fix, nothing else. Your debug lines are still right there in index.html, unstaged, ready for you to keep poking at the bug — or just git restore index.html to throw them away once you're done, without touching the commit you already sealed.
Naming the three areas properly
- Working directory — the actual files on disk. What your editor shows you, right now, edited or not.
- Staging area (Git's manual calls it "the index") — your portioned pile. Marked as ready, not yet permanent.
- Repository — the sealed boxes. Every commit you've made, living inside
.git/, exactly as Chapter 3 described.
Every command you've used so far, and most of what's coming, is just a movement between these three places:
| Command | Moves from | To |
|---|---|---|
git add <file> | Working dir | Staging (whole file) |
git add -p | Working dir | Staging (chosen hunks) |
git commit | Staging | Repository |
git commit -a | Working dir (tracked files) | Repository — skips staging entirely |
git restore --staged <file> | Staging | Back to working dir (unstage, keep edits) |
git restore <file> | Repository (last commit) | Working dir (discard edits) |
The trap: editing after staging
One thing catches almost everyone once. Say you'd staged the nav fix, then kept editing index.html a little more before committing — maybe you tightened the CSS further. That later edit does not retroactively update what you staged. Staging captured a snapshot at the moment you ran git add; anything you type afterward is a fresh, separate, unstaged change sitting on top of it.
If you commit right now, only the staged version ships. Run git add again first if you want your later edits included too. This is exactly why git status before every commit is worth the two seconds — it's the only place that shows you both piles at once.
index.html with git add, then edited index.html again. You run git commit right now. What gets recorded?git add, not a live link to the file. Whatever you typed after that moment sits in the working directory, unstaged, until you stage it too.
The commit's in. Anvesha approves it at 5:03. But now it's the following Thursday, the "temporary" homepage preview you've been sharing with the Board looks subtly broken — a spacing issue that definitely wasn't there Monday — and nobody remembers which of the forty-odd commits since then caused it.