Undoing and ignoring
Which tool to reach for depends on how far the change already went. Telling restore, reset, and revert apart is the whole point of this step.
What you'll learn
- You can safely throw away changes you haven't committed
- You can safely undo a commit that others already pulled
- You keep build output and secrets out of the repository with .gitignore
Which tool you need depends on how far the change already travelled. Not committed yet: git restore. Committed but not pushed: git reset. Already pushed and pulled by others: git revert. Mix these up and you break other people's history, so make it a habit to check where you stand with git status first.
git reset comes in three flavours. --soft undoes the commit but leaves the changes staged; the default --mixed also unstages them; --hard throws the file contents away as well. --hard really does delete your work, so read the command once more before you press enter. Even then, don't give up immediately — git reflog often still holds the commit you lost.
Build output, node_modules, and secret files like .env must never enter the repository. Put a .gitignore at the project root and GIT stops looking at those paths entirely. Careful though: a file already committed stays tracked no matter what you add to .gitignore. Then you must untrack it with git rm --cached and commit — and if a password already went up, rotate the secret itself, because it lives on in history.
Commands for this step
Don't just read them — type them into a real terminal. Your hands have to remember, not your eyes.
git restore <file>- Discard uncommitted changes to a file and return it to the last commit.
git reset --soft HEAD~1- Undo the last commit but keep its changes staged — the usual way to reword a message.
git revert <commit>- Create a new commit that undoes that one. History stays intact, so it's safe on shared branches.
git diff --staged- Review what you staged before committing. Make it a habit right before every commit.