Everyone breaks something in Git eventually. You commit to the wrong branch, push a bug, reset away a morning’s work. The good news: Git almost never throws data away, and nearly every mistake has a clean undo. The trap is reaching for whichever undo command you half-remember. Pick by asking one question: where does the mistake live?
\n| Where the mistake is | \nCommand | \nRewrites history? | \n
|---|---|---|
| Unstaged edits in a file | \ngit restore <file> | \nNo (but discards the edits) | \n
| Staged, not committed | \ngit restore --staged <file> | \nNo | \n
| Last commit, not pushed | \ngit commit --amend | \nYes, your local commit only | \n
| Local commits, not pushed | \ngit reset | \nYes, local only | \n
| Commits already pushed and shared | \ngit revert <commit> | \nNo | \n
The table follows a single rule: once other people have a commit, you add new commits on top instead of changing it.
\nForgot a file or wrote a bad message, and haven’t pushed?
\ngit add contact.css\ngit commit --amend --no-edit # same message, file included\ngit commit --amend -m \"Add contact form\" # or a new messageAmend doesn’t edit the commit; it replaces it with a new one with a new ID. That’s fine locally and a problem if you’ve pushed, for the same reason rebase is.
\nYou merged a commit to main that broke the mobile nav. It’s pushed, and teammates have pulled. Don’t rewrite anything. Add a commit that reverses it:
git revert HEAD # if it's the latest commit\ngit revert 8f1e2aa # or any commit by IDGit creates a new commit, Revert "Move nav into header", that applies the exact opposite changes. History still shows the mistake and its fix, which is honest and safe: everyone gets the revert with a normal pull. To revert a merge commit, tell Git which parent to keep as the mainline, usually the first: git revert -m 1 <merge-commit>.
Sometimes only part of a commit was wrong. If the nav move was fine except for styles.css, you don’t need to revert the whole thing. Bring that one file back to how it was before the commit, check it, and commit the result as an ordinary fix:
git restore --source=8f1e2aa~1 styles.css\ngit diff\ngit commit -am \"Restore mobile nav styles\"That’s still “adding history, not rewriting it”, just with a smaller scope.
\ngit reset <commit> moves the current branch to another commit. What it does to the index and working tree depends on the mode, and this is where people get hurt.
Three situations, three modes:
\ngit reset --soft HEAD~2 # squash: the last two commits' changes become staged, ready for one commit\ngit reset HEAD~1 # un-commit (--mixed): changes return as unstaged edits to rework\ngit reset --hard HEAD~1 # discard: the commit and its changes are gone from the branch and filesA classic use: you committed to main when you meant to be on a branch. Commit or stash any uncommitted edits first (--hard would wipe them), create the branch where you are, then move main back:
git branch contact-form # the branch keeps your commit\ngit reset --hard origin/main # main goes back to match GitHub\ngit switch contact-formHere’s the safety net that makes all of this less frightening. Every time HEAD moves (commit, switch, reset, rebase, merge), Git writes a line in the reflog:
\ngit reflog2b7f0c1 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3\n9e4a1d5 HEAD@{1}: commit: Add contact form validation\n4c8b2e7 HEAD@{2}: commit: Add contact form\na71d3f0 HEAD@{3}: checkout: moving from footer to mainAfter that accidental git reset --hard HEAD~3, the three commits aren’t on any branch, but they still exist and HEAD@{1} points at the newest. Bring them back:
git reset --hard HEAD@{1} # put main back where it was\n# or, more cautiously, keep them on a new branch to inspect first\ngit switch -c rescue 9e4a1d5The reflog is local (it isn’t pushed or cloned) and entries expire: by default after 90 days, or 30 days for commits no branch can reach. That’s plenty of time to notice a mistake.
\nWhat the reflog can’t save is work that was never committed. git restore and git reset --hard overwrite uncommitted edits in your files, and no log knows about them. So the real safety habit is simple: commit early and often on your branch. You can always squash commits before review; you can’t recover edits you never committed.
Some work-in-progress isn’t ready for a commit, though. Next you’ll park it with git stash, and stop Git from tracking files it never should.
git revert <commit> adds a new commit that cancels an old one, which is the safe way to undo anything already pushed.","git reset moves the current branch: --soft keeps changes staged, --mixed keeps them unstaged, --hard discards them.","git commit --amend replaces the last commit, so use it only before pushing.","git reflog lists where HEAD has been, so commits lost to a reset or rebase can be found and restored for weeks afterwards."],"further":[{"title":"Undoing Things (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things"},{"title":"Reset Demystified (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified"},{"title":"git revert reference","url":"https://git-scm.com/docs/git-revert"},{"title":"git reflog reference","url":"https://git-scm.com/docs/git-reflog"}],"quiz":[{"q":"You committed “Add contact form” a minute ago, haven’t pushed, and realise you forgot to stage contact.css. What’s the cleanest fix?
git revert HEAD, then commit again with both files.","why":"That leaves two extra commits (the original and its reversal) in history for a mistake nobody else has seen."},{"text":"git reset --hard HEAD~1 and redo the work.","why":"--hard discards the committed changes from your files. You’d be rewriting the form by hand."},{"text":"git add contact.css, then git commit --amend --no-edit.","why":"Correct. Amend replaces the unpushed last commit with one that includes the file; --no-edit keeps the message."},{"text":"git restore --staged contact.css","why":"That unstages a file. contact.css isn’t staged yet, and the commit would still be missing it."}],"answer":2},{"q":"Yesterday you merged a commit to main that broke the mobile nav. It’s pushed and your teammates have pulled. How do you undo it?
git revert <commit> and push the new commit.","why":"Correct. Revert records a new commit that applies the opposite change, so nobody’s history is rewritten and everyone gets the fix with a normal pull."},{"text":"git reset --hard <commit>~1 and git push --force.","why":"That rewrites shared history. Teammates still have the bad commit, and their next push brings it back or creates a mess."},{"text":"git commit --amend to edit the bad commit away.","why":"Amend only touches your latest commit, creates a new ID, and would also need a force-push to a shared branch."},{"text":"git restore --source=HEAD~1 . and push without committing.","why":"Restoring files changes only your working tree. Nothing is pushed until it’s committed."}],"answer":0},{"q":"You run git reset --soft HEAD~2 on two unpushed commits. Where are their changes now?
--hard. --soft never touches the index or the working tree."},{"text":"In your working tree but unstaged.","why":"That’s the default --mixed mode, which also resets the index."},{"text":"Still in the two commits, which are now on a new branch.","why":"Reset doesn’t create branches. It moves the current branch pointer."},{"text":"Staged in the index, ready to be committed again as one commit.","why":"Correct. The branch moved back two commits but the index and files kept everything, a quick way to squash local commits."}],"answer":3},{"q":"You ran git reset --hard HEAD~3 by mistake and three commits vanished from git log. How do you get them back?
--hard deletes commits permanently.","why":"Reset moves a pointer. The commits still exist, and the reflog remembers where HEAD was."},{"text":"Run git reflog, find the entry from before the reset, and git reset --hard HEAD@{1}.","why":"Correct. HEAD@{1} means where HEAD was one move ago, which is right before the reset."},{"text":"Run git revert HEAD~3.","why":"Revert creates a new commit undoing a change. It doesn’t restore lost commits to your branch."},{"text":"Run git pull, which restores any missing commits.","why":"Only if they were pushed. Pull fetches what’s on the remote; unpushed commits exist only in your local repository."}],"answer":1}],"exercise":{"kind":"choice","multiple":false,"options":["a","b","c","d"],"correct":["b"],"title":"Pick the undo","prompt":"Your most recent commit on main, 8f1e2aa Move nav into header, broke the mobile menu. You pushed it an hour ago and two teammates have already pulled. git status shows a clean working tree.
8f1e2aa (HEAD -> main, origin/main) Move nav into header\nc39be11 Add projects page\nb2e04f3 Add navigation bar with base stylesWhich command should you run before pushing again?
\n","hints":["Ask where the mistake lives: your files, the index, a local commit, or a shared commit?","Anything that changes8f1e2aa itself would need a force-push to a branch others have pulled.","You want to add history, not rewrite it."],"explanation":"The bad commit is already shared, so rewriting it (amend or reset) would force everyone else to repair their history. git revert HEAD adds a new commit that applies the exact opposite of 8f1e2aa; push it normally and your teammates get the fix with an ordinary pull. Later you can fix the nav properly on a branch and bring the move back through a pull request.
git reset --hard HEAD~1, then git push --force","why":"This deletes a commit your teammates already have. Their next push can bring it back, and the force-push may wipe out anything pushed in the meantime."},"b":{"text":"git revert HEAD, then git push","why":"Correct. The new commit cancels 8f1e2aa without rewriting shared history."},"c":{"text":"git restore index.html","why":"The working tree is clean, so there’s nothing to restore. The bug is inside a commit, and only a new commit can undo it publicly."},"d":{"text":"git commit --amend","why":"Amend replaces the latest commit with a new ID, which is a rewrite of a pushed commit and would need a force-push."}}},"words":719,"readMinutes":3}