Undoing Mistakes: reset, revert, checkout

Undoing uncommitted changes

git checkout -- index.html      # discard uncommitted changes to one filengit restore index.html          # the newer, equivalent command

This throws away changes you have made but not yet committed, restoring the file to how it looked at your last commit — useful when you have gone down a wrong path and just want a clean slate for that file.

Unstaging a file

git reset index.html

This moves a file back out of the staging area without touching its actual content — useful if you ran git add . too broadly and want to un-stage one file before committing.

git revert — the safe way to undo a commit

git revert <commit-hash>

revert creates a brand new commit that undoes the changes from an earlier one, while keeping the original commit intact in history. This is the safe choice for anything already pushed and shared with others — it never rewrites history, so it cannot cause the confusing conflicts that rewriting shared history can create for collaborators.

git reset — rewriting history (use with care)

git reset --soft HEAD~1     # undo the last commit, keep the changes stagedngit reset --hard HEAD~1     # undo the last commit AND discard the changes entirely

reset --hard is genuinely destructive — it permanently discards changes with no confirmation prompt. Never use reset on commits you have already pushed and that someone else might have already pulled; revert is the correct tool for that situation instead.

A good rule of thumb

If a commit is only on your machine and nobody else has seen it, reset is fine. Once you have pushed it and it is possible someone else has pulled it, reach for revert instead.