Stage some things, leave others
You do not have to photograph everything at once.
git add takes file names — stage the files that belong to one idea, and let the rest wait for their own commit.
01Picking files by name
git add accepts any number of file names, not just the dot. Stage the two files that belong to one idea; leave the third file — the unrelated mess you are still working on — for its own photograph later. This is the whole reason the staging area exists as a separate step.
The payoff is history that reads like a story. Six months from now, someone reading your log sees add login page containing exactly the login page — not the login page glued to half a settings menu. That someone is usually you.
git add login-page.txt
git commit -m "add login page"
git add notes.txt
git commit -m "update notes"02Taking a file off the checklist
Staged something and changed your mind? git restore --staged <file> removes it from the checklist. Read the flag carefully, because the two forms of restore do very different jobs: --staged only unstages — the file keeps its changes on disk and simply goes back to waiting. Nothing is lost. It is the undo button for the checklist alone.
Notice how git phrases this in the status hints: under Changes to be committed it literally prints (use "git restore --staged <file>..." to unstage). Git is teaching you the command in the exact moment you need it — that is what those bracketed hints are for.
git add notes.txt
git restore --staged notes.txtgit restore --staged file unstages but keeps your edits. git restore file (next courses) throws your edits away. The flag is the difference between tidy and gone — always double-check which one you typed.
03Reading a mixed status
Once you stage selectively, status starts showing two groups at once — some files staged, others not. That is not an error; it is the checklist doing its job, holding one idea while another waits. The practice below sets up exactly that mixed situation on purpose, because reading it comfortably is the skill.
There is a stronger cousin for a specific situation: git rm --cached file takes a file out of git's tracking entirely while keeping it on disk — the way you rescue a file that was committed before .gitignore existed. You will meet it in the next course.
Practice
Two files, one idea at a time.
01.Stage only a.txt, not b.txt.
hint: Try: git add a.txt
02.Take a.txt back off the checklist with git restore --staged.