I Staged Something by Mistake
You ran git add ., you ran git status out of habit, and there in the list of things about to be committed is a file that has no business being there.
Nothing is lost and nothing is at risk. The change is in the staging area; taking it back out moves it to the working directory, and your edits are untouched. This is the safest page in the chapter.
Diagnose
git status
The file is listed under changes to be committed. That is the staging area — the second of the three places, and the box from Chapter 2.
Take it out of the box
git restore --staged notes.txt
Run git status again and the file has moved: back under changes not staged if Git was already tracking it, or back to untracked if it was new. Either way the file itself is byte for byte what it was a moment ago.
The command takes one file at a time, so the rest of the box stays packed. There is no need to unstage everything and start again.
Why this one is completely safe
Compare it to the previous page. Discarding an unstaged change destroys it because nothing recorded it. Unstaging moves a change between two places that both still hold it — the working directory is where the contents live, and staging is only a note about what goes into the next commit.
The distinction is worth internalizing: commands that move things between places are safe; commands that overwrite the working directory are not.
On Sandpiper: you finish the sightings script, run git add . without looking, and git status shows notes.txt going in with it — the scribbled list of who is bringing what to the summer outing, which is nobody's business but the club's. One command puts it back.
The older spelling
Git's own hints have historically suggested git reset HEAD notes.txt for this, and plenty of tutorials still do. It achieves the same thing here.
git restore --staged is the modern, narrower spelling, and it has the advantage of saying what it does. This book uses it and mentions reset exactly twice: here, and on the revert page, both times as a word to recognize rather than a tool to reach for.
The real fix
If you keep unstaging the same file, the problem is not your attention span. Some files should never be candidates for committing at all — private notes, passwords, things your computer generates — and Chapter 5 is where you tell Git to stop offering them.
Vigilance is a bad long-term strategy. A four-line configuration file is a good one.
- "Unstaging deletes my changes." It moves them back one step. The file's contents are exactly where you left them, which
git diffwill show you immediately. - "The file is now safe from being committed." It is out of the box for this commit only. The next
git add .will sweep it straight back in unless you ignore it properly. - "I have to unstage everything and start over." The command takes one file. Everything else you carefully staged stays staged.
- "If I unstage a new file it becomes untracked again, so I have lost it." Untracked means Git is not recording it; the file is still sitting in your folder, unchanged and openable.
git add .is the single most common route by which beginners commit something that should never enter a repository, and a one-command undo removes the panic from that discovery.- This is the clearest demonstration that the three places are real and that changes move between them in both directions — the model from Chapter 2 doing visible work.
- Knowing which commands move and which overwrite is a better mental filter than memorizing which ones are dangerous.
Knowledge Check
What happens to a file's contents when you unstage it?
- Nothing at all, since the contents stay exactly as you had last edited them
- They are reverted to whatever was in the most recent commit of that file
- They are copied into a temporary area and removed from the working directory
- They are committed immediately so that the staged version is not lost
Why is unstaging safe when discarding an unstaged change is not?
- Because the file's contents live in the working directory in either case
- Because Git keeps a backup of every staged file until the next commit is made
- Because unstaged changes are stored in the history while staged ones are not
- Because the staging area is written to disk and the working directory is not
You unstage a file that Git had never recorded before. What does git status show?
- It appears as untracked again, and the file is still in your folder
- It disappears from the status output entirely until it is edited again
- It appears under changes not staged, because Git now tracks it permanently
- It is deleted from the folder, because Git had no committed version to keep
You keep accidentally staging the same private file. What is the real fix?
- Tell Git to ignore the file, which is what Chapter 5 is about
- Stop using
git add .and add every file by name from now on - Move the file outside the project folder so that Git cannot reach it
- Delete the file after each commit and recreate it when you next need it
You got correct