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.
- 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.
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.