If you pushed a commit and immediately started sweating, welcome to the club. This guide will help you undo a pushed Git commit with minimal drama. We will cover when to pick git revert versus git reset, how to push safely after a reset, and how to check that you did not accidentally erase someone else life work. Keep version control sane and your coworkers calmer than before.

Assess the situation

First question to ask yourself while breathing into a paper bag: has the bad commit been shared with others? If the answer is yes, do not rewrite history on the shared branch unless you like awkward team messages and merge conflicts. If the branch is private and you are the only one working on it, a history rewrite may be fine.

Quick decision guide

• Shared branch or main branch, prefer git revert and preserve history
• Private feature branch and you know what you are doing, git reset then force push can work
• When in doubt, revert. Your teammates will thank you silently or with passive aggressive emojis

Use git revert to make a reversing commit

git revert is the safe route. It creates a new commit that undoes the changes from the bad commit while leaving history intact. No mysterious rewrites, no missing commits, and fewer angry pings in chat.

git revert     # creates a new commit that reverses the target commit
git push origin your-branch

Use this on shared branches to avoid rewriting history. If the commit touched multiple files or needs manual resolution, Git will open your editor or show conflicts for you to fix.

Use git reset when rewriting history is acceptable

Reset is more forceful. It moves your branch pointer and can remove commits from the branch history. This is fine on feature branches that only you use, and risky everywhere else.

git reset --hard     # move branch back and replace working tree
# then push the rewritten branch to remote
git push --force-with-lease origin your-branch

Never do a plain force push without telling people. Force with lease reduces the chance of clobbering someone else work by checking for upstream changes first.

Push after reset and stay out of trouble

• Prefer git push --force-with-lease to a plain force push
• If someone did push to the branch in the meantime, the lease will stop the push and prompt a manual check
• Explain why you rewrote history in your team chat and link to the commit range if useful

Verify the remote state

Always confirm the remote is how you expect. Don't trust faith or hope. Use these commands to inspect the remote branch history and to fetch any updates.

git fetch origin
git log --oneline origin/your-branch
# or compare local and remote
git log --oneline your-branch..origin/your-branch

Practical tips and etiquette

• If unsure prefer revert since it preserves history and avoids surprises
• Communicate before and after a force push to reduce emergency reactions
• Use clear commit messages when reverting so future humans know why the reversal happened
• Consider protecting important branches to prevent accidental force pushes

Recap and quick cheat sheet

git revert creates a new reversing commit and keeps history. Use it on shared branches for safety. git reset rewrites history and requires a force push afterwards. Use git push --force-with-lease if you must push after a reset. Always fetch and inspect the remote after any change and tell your team what you did.

Cheat sheet commands

# safe revert on shared branch
git revert 
git push origin your-branch

# history rewrite on private branch
git reset --hard 
git push --force-with-lease origin your-branch

# verify remote
git fetch origin
git log --oneline origin/your-branch

Now go forth and undo with care. If you made a mistake again, at least you will be better prepared and funnier in the apology message.