--- title: "Pushed a bad commit to a shared branch? Undo it with git revert" description: "git revert records a new commit that reverses the bad one, so history stays as it is and your teammates lose nothing. Keep git reset and push --force for branches only you use." url: https://ihsanalapsi.dev/articles/git-revert-pushed-commit lang: en date: 2026-11-02 updated: 2026-11-02 tags: ["Developer tools", "Web development"] author: Ihsan Alapsi (إحسان العبسي) --- # Pushed a bad commit to a shared branch? Undo it with git revert The command that wipes a mistake out of history is the one that makes it bigger for your team, and the command that adds a new commit is the one that fixes it. If you pushed a commit that broke something on a shared branch, below you will see how to undo it with git revert without touching anyone's history: one commit, several commits, or a merge, and what to do if a conflict stops you halfway. ## What does git revert do? git revert is a command that takes an existing commit, reverses the changes it introduced, and records that reversal in a new commit. The bad commit stays in history, and on top of it sits a commit that cancels its effect. According to the [git revert page in the Git documentation](https://git-scm.com/docs/git-revert), the command needs a clean working tree, meaning no changes from the last commit (HEAD). So if you have unsaved work, commit it before you start. ## Why is git reset not the fix for a pushed commit? Because git reset moves the tip of the branch back and changes history, and teammates who already pulled the bad commit end up with work built on a history that no longer exists on the server. The [main git page in the documentation](https://git-scm.com/docs/git) separates the three commands in its "Reset, restore and revert" section: revert makes a new commit that reverses older commits, restore brings back files and does not update your branch, and reset moves the tip of the branch to add or remove commits, which changes the commit history. The usual mistake is a simple one: you reset on your machine, the push is rejected, so you push with --force. That overwrites the history on the server. The [Pro Git section on the perils of rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) describes this exact case: someone runs git push --force to overwrite the history on the server, their teammates have to re-merge their work, and things get messy. Its rule fits in one line: do not rewrite commits that exist outside your repository and that people may have based work on. ## How do you undo one commit, step by step? You find the hash of the bad commit, run git revert on it, and push the new commit like any normal commit. 1. Pull the latest version of the branch and make sure your working tree is clean. You end up with the same branch as the server. 2. Find the bad commit in the log: ```bash git log --oneline ``` 3. Revert it by the hash you found. Without options, git opens the commit message editor, and with `--no-edit` it does not: ```bash git revert --no-edit HASH ``` 4. Push the new commit with a normal git push, without `--force`. Your teammates pull it like any other commit, and nobody loses anything. If the commit is not the latest one, you can name it by its position from HEAD. The documentation's example `git revert HEAD~3` reverts the fourth last commit and creates a new commit with the reversal. ## How do you undo several commits in one commit? You use `-n` (or `--no-commit`): git revert applies the reversal to your working tree and the index without making a commit, and you make one commit at the end. The documentation gives this example: ```bash git revert -n master~5..master~2 ``` This reverts the commits from the fifth last commit in master (included) to the third last (included), and only changes the working tree and the index. Then review the changes and make one commit with a message that explains why you reverted them. The documentation says `-n` is useful for exactly this: reverting the effect of several commits in a row. ## What if the bad commit is a merge? A merge has more than one parent, so git revert cannot tell on its own which side is the mainline, and you choose it with `-m` and the parent number, counting from 1. ```bash git revert -m 1 MERGE_HASH ``` But note what the documentation says plainly: reverting a merge declares that you will never want the changes that merge brought in. So if you merge the same branch again later, only changes from commits that are not part of the reverted merge come in. If you fix the branch and want to merge it again, plan for that before you merge. ## What do you do if there is a conflict? If git revert stops on a conflict, you either resolve it and go on with `git revert --continue`, or cancel everything with `git revert --abort` and return to the state before. Resolve it like any conflict: open the files, pick the right version, add them to the index, then `--continue`. And if you feel lost, `--abort` takes you back to where you started. ## Where do you start now? If you have a bad commit on a shared branch today, run `git revert --no-edit` on it and push it without `--force`. And if you are used to fixing things with reset, keep that for branches only you use. The lesson for us as developers: shared history belongs to the whole team, so a fix on it is a new commit that reverses the mistake. That way everyone pulls the fix like any commit, and nobody finds their work built on a history that vanished. Better than undoing is catching the mistake before the merge: see our article on [AI code review on GitHub](/articles/ai-code-review-github-claude-ga), and the one on [locking action versions in your workflow](/articles/github-actions-workflow-lockfiles) so nothing changes under you without you knowing. And if you are still building your base as a programmer, the [Programmer Roadmap 2026](/products/roadmap-2026) gives you the order. ## FAQ **What is the difference between git revert and git restore?** git revert makes a new commit that reverses older commits. git restore brings back files in the working tree from the index or from another commit, and it does not update your branch. **Why does git revert refuse to run for me?** Usually because you have uncommitted changes. git revert needs a clean working tree, with no changes from the HEAD commit. Commit your changes first, then try again. **When do I use git reset instead of git revert?** When the commit is not pushed yet, or is on a branch nobody else works on. git reset moves the tip of the branch and changes history, which breaks the work of anyone who built on the old commits. **Do I need -m with every revert?** No, only when the commit you want to undo is a merge. Then -m gives the parent number git treats as the mainline, counting from 1.