Git Reset vs Revert: How to Safely Undo Commits
Confused by git reset vs revert? Learn when to use each command to undo git commits safely without breaking your team's shared history.
We’ve all been there: you push a feature branch, realize you accidentally included a debug log or a broken API call, and panic. You want to undo your last action, but you aren't sure if you should reach for reset or revert. Choosing the wrong one can cause a headache for everyone else on your team.
The core rule is simple: if the code has left your machine and is sitting on a shared remote, you generally shouldn't rewrite history. If you're working locally on a sandbox branch, you have more freedom.
Understanding Git Reset vs Revert
The fundamental difference between these two tools is how they manipulate the commit graph. git reset is a surgical tool that moves your branch pointer to a previous state, effectively "erasing" history. git revert, on the other hand, is a additive tool; it creates a new commit that does the exact opposite of a previous one.
| Command | Action Type | History Impact | Best For |
|---|---|---|---|
git reset | Destructive | Rewrites history | Local, unpushed work |
git revert | Additive | Keeps history | Shared, public branches |
When to Use Git Reset
I use git reset almost exclusively for local cleanup. If I have three "fix linting" commits that I don't want in the permanent record, I’ll reset my branch to the state before those commits and squash them into one.
There are three main modes for git reset:
- --soft: Moves the branch pointer back but keeps your changes in the staging area.
- --mixed (default): Moves the pointer back and unstages your changes.
- --hard: Moves the pointer back and destroys your changes.
Warning: Never use git reset --hard unless you are absolutely certain you don't need the work currently in your working directory. I once lost about two hours of work on a Friday afternoon because I was moving too fast and assumed I had committed my changes.
Why You Should Use Git Revert on Public Branches
When you need to undo git commits that have already been pushed to main or develop, git revert is your only safe option. Because it adds a new commit, it doesn't break the history for your teammates. If you were to use reset on a shared branch, their local environments would diverge from the remote, and they’d be stuck dealing with a messy "rebase" nightmare.
To revert a specific commit, you just need the hash:
Bashgit revert <commit-hash>
Git will open your editor to create a new "revert commit." This creates a clear trail: Commit A added the bug, and Commit B reverted the changes from Commit A. This transparency is vital for debugging later.
Best Practices for Your Git Workflow
If you find yourself needing to move code between branches to fix a mistake, remember that Git Cherry-Pick: How to Move Commits Between Branches Safely is often a better alternative than trying to manually reset or revert complex commit chains.
Here is my personal checklist for when things go wrong:
- Is the code pushed? If no, use
reset --softto clean up your commits. - Is the code merged into a shared branch? If yes, always use
git revert. - Did I accidentally commit sensitive data? Use
git resetlocally, but if it's already pushed, you need to rotate those credentials immediately. Refer to Secret management best practices: Secure your Node.js and PHP apps to ensure this doesn't become a recurring security incident.
Frequently Asked Questions
What happens if I use reset on a shared branch? You create a "diverged history." When your teammates try to pull, Git will complain that their local branch is behind the remote, and they will likely have to merge your forced changes, which often results in duplicate commits or lost work.
Can I revert multiple commits at once?
Yes. You can pass a range to git revert (e.g., git revert HEAD~3..HEAD) to create individual revert commits for each one in the range.
Is there a way to undo a revert? Yes, you simply revert the revert commit. Since a revert is just a standard commit, Git treats it like any other change.
Final Thoughts
I still occasionally reach for git reset --hard when I'm deep in a local experiment, but I've learned to "git status" about three times before hitting enter. The biggest takeaway? History is meant to be a record of what happened. If you use revert to fix mistakes, you tell a story about how your project evolved, including the lessons learned along the way. If you use reset on public branches, you're just hiding the truth—and usually making life harder for everyone else on the team.