"I staged the wrong file"
A private scratch file got staged by accident. Unstage it without losing a single word of it.
You are jotting a scrambled eggs recipe into eggs.md, and a genuinely private scratch file — notes.txt, a couple of personal reminders — happens to be sitting in the same folder. git add sweeps up both at once, and now notes.txt is staged for a commit it was never meant to be part of.\n\nThis is not a crisis. Staging is not committing — the staging area is a real, genuine waypoint, not a one-way door. git restore --staged moves a file back out of it, with every word of its content completely untouched.
Two Files Staged, Only One Belongs
git add eggs.md notes.txt
git status
Both are genuinely staged now. notes.txt was never meant to be part of any commit — it is a private scratch file, not a recipe.
Unstaging Without Losing Anything
git restore --staged notes.txt
notes.txt moves back to being untracked — its content is completely untouched, it is simply no longer queued for the next commit. eggs.md stays staged.
The Older Syntax, Doing the Same Thing
git add notes.txt # staged again, on purpose, to demonstrate
git reset HEAD notes.txt # the pre-2.23 way to unstage
Both commands genuinely produce the identical result. git restore --staged (introduced in Git 2.23, 2019) is the modern, clearer-named replacement — but you will still see git reset HEAD <file> in a lot of real tutorials and older codebases.
git restore --staged <file>
Moves a file out of the staging area and back to being unstaged (or untracked, for a new file), without touching its actual content in any way. Confirmed directly in this lab: notes.txt's content was identical before staging it and after unstaging it.
git reset HEAD <file>
The older, pre-2.23 syntax for the exact same operation as git restore --staged. Confirmed directly in this lab producing an identical result. Still common in older tutorials and scripts, which is why recognizing it matters even though restore is the modern default.
📝 Stage Both Files by Accident
Create a real recipe and a private scratch file, then stage both at once — exactly the accident this lesson is about.
cd ~/recipes && printf 'Scrambled Eggs\n\nWhisk eggs, cook low and slow, stir constantly.\n' > eggs.mdcd ~/recipes && printf 'call mom about thanksgiving turkey order\nask dave about the grocery budget spreadsheet\n' > notes.txtcd ~/recipes && git add eggs.md notes.txtcd ~/recipes && git statusstudent@lab:~$ cd ~/recipes && printf 'Scrambled Eggs\n\nWhisk eggs, cook low and slow, stir constantly.\n' > eggs.md student@lab:~$ cd ~/recipes && printf 'call mom about thanksgiving turkey order\nask dave about the grocery budget spreadsheet\n' > notes.txt student@lab:~$ cd ~/recipes && git add eggs.md notes.txt student@lab:~$ cd ~/recipes && git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: eggs.md new file: notes.txt
↩️ Unstage the Scratch File
Move notes.txt out of the staging area with git restore --staged, and confirm eggs.md stays staged.
cd ~/recipes && git restore --staged notes.txtcd ~/recipes && git statusstudent@lab:~$ cd ~/recipes && git restore --staged notes.txt student@lab:~$ cd ~/recipes && git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: eggs.md Untracked files: (use "git add <file>..." to include in what will be committed) notes.txt
🔁 See the Older Syntax Do the Same Thing
Stage notes.txt again on purpose, then unstage it with the older git reset HEAD syntax — confirm it produces the identical result.
cd ~/recipes && git add notes.txtcd ~/recipes && git reset HEAD notes.txtcd ~/recipes && git statusstudent@lab:~$ cd ~/recipes && git add notes.txt student@lab:~$ cd ~/recipes && git reset HEAD notes.txt student@lab:~$ cd ~/recipes && git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: eggs.md Untracked files: (use "git add <file>..." to include in what will be committed) notes.txt
📸 Commit the Recipe Alone
Commit eggs.md by itself, and confirm notes.txt is still genuinely untracked and untouched.
cd ~/recipes && git commit -m 'Add scrambled eggs recipe'cd ~/recipes && git log --oneline -1cd ~/recipes && git statusstudent@lab:~$ cd ~/recipes && git commit -m 'Add scrambled eggs recipe' [master c15f716] Add scrambled eggs recipe 1 file changed, 3 insertions(+) create mode 100644 eggs.md student@lab:~$ cd ~/recipes && git log --oneline -1 c15f716 (HEAD -> master) Add scrambled eggs recipe student@lab:~$ cd ~/recipes && git status On branch master Untracked files: (use "git add <file>..." to include in what will be committed) notes.txt nothing added to commit but untracked files present (use "git add" to track)
Lab 1.4.1 complete. A wrong file staged, unstaged cleanly, content never at risk:\n\n\n Wrong file staged by accident : ✅ genuine mistake, staged\n Unstaged with git restore : ✅ content fully intact\n Older syntax confirmed equal : ✅ git reset HEAD <file>\n Correct file committed alone : ✅ confirmed via log + status\n
Enable JavaScript to run the live terminal and track your progress.