Introduction

A git revert creates a new commit that undoes the changes from a previous commit, which is the safe way to undo work on shared branches. But sometimes the revert itself was a mistake, and you need to undo it. Depending on whether the revert has been pushed to a remote, you have several strategies available, each with different tradeoffs around history cleanliness and team impact.

How git revert Works

Before canceling a revert, it helps to understand what happened. git revert does not delete a commit. It creates a new commit whose changes are the exact inverse of the target commit.

A --- B --- C --- D        (before revert)
A --- B --- C --- D --- D' (after "git revert D")

Commit D' contains the opposite of every change in D. The original commit D remains in history. This is why reverting is safe for shared branches, but it also means canceling the revert requires adding yet another commit or rewriting history.

Method 1 - Revert the Revert Commit

The safest approach, and the only one suitable when the revert has already been pushed to a shared branch, is to revert the revert commit itself.

1# View the log to find the revert commit hash
2git log --oneline -5
3# e4f5g6h Revert "Add payment processing"
4# a1b2c3d Add payment processing
5# ...
6
7# Revert the revert
8git revert e4f5g6h

After this, the history looks like this.

A --- B --- C --- D --- D' --- D''

Commit D'' reapplies the original changes from D by inverting D'. The net effect is that D's changes are restored. This approach is completely safe for shared repositories because it only adds new commits.

# Verify the file content matches the original
git diff a1b2c3d..HEAD -- path/to/changed/file
# Should show no differences if the revert-of-revert restored everything

Method 2 - git reset (Before Pushing)

If the revert commit has not been pushed yet, you can remove it entirely with git reset. This keeps the history clean by erasing the revert commit as if it never happened.

1# Soft reset preserves changes in the staging area
2git reset --soft HEAD~1
3
4# Or mixed reset (default) preserves changes in working directory
5git reset HEAD~1
6
7# Or hard reset discards everything
8git reset --hard HEAD~1

After a hard reset, the history returns to its state before the revert.

Before reset:  A --- B --- C --- D --- D'
After reset:   A --- B --- C --- D

Use --soft when you want to inspect the staged changes before deciding what to do. Use --hard only when you are certain you want to discard the revert completely.

1# Confirm the revert commit is gone
2git log --oneline -3
3# a1b2c3d Add payment processing
4# ...

Warning - Never use git reset to remove commits that have already been pushed to a shared branch. Other team members who have pulled those commits will encounter conflicts.

Method 3 - Interactive Rebase to Drop the Revert

If the revert commit sits among several local commits that have not been pushed, an interactive rebase lets you selectively remove it while keeping other commits.

# Start interactive rebase going back 3 commits
git rebase -i HEAD~3

This opens an editor showing recent commits.

pick a1b2c3d Add payment processing
pick e4f5g6h Revert "Add payment processing"
pick i7j8k9l Update documentation

Change pick to drop (or delete the line) for the revert commit.

pick a1b2c3d Add payment processing
drop e4f5g6h Revert "Add payment processing"
pick i7j8k9l Update documentation

Save and close the editor. Git replays the remaining commits without the revert.

Before:  A --- B --- C --- D --- D' --- E
After:   A --- B --- C --- D --- E'

Note that commit E' gets a new hash because its parent changed. This is a history rewrite, so only use this method on commits that have not been pushed.

Recovering from a Pushed Revert

When a revert has been pushed and other developers have pulled it, your only safe option is Method 1 (revert the revert). Attempting to reset or rebase a shared branch causes divergent histories and forces everyone to reconcile their local copies.

Here is the complete workflow for recovering from a pushed revert.

1# Step 1: Identify the revert commit
2git log --oneline --grep="Revert" -5
3# e4f5g6h Revert "Add payment processing"
4
5# Step 2: Revert the revert
6git revert e4f5g6h
7
8# Step 3: Push the fix
9git push origin main
10
11# Step 4: Notify the team
12# The history now shows the original commit, its revert, and the re-application

If the original commit that was reverted contained conflicts with newer code, the revert-of-revert may produce merge conflicts. Resolve them as you would any merge conflict.

1# If conflicts occur during the revert-of-revert
2git revert e4f5g6h
3# CONFLICT (content): Merge conflict in src/payment.py
4
5# Resolve conflicts manually, then
6git add src/payment.py
7git revert --continue

Using git reflog as a Safety Net

If you accidentally ran git reset --hard and lost the revert commit that you actually wanted to keep, git reflog records every HEAD movement and lets you recover.

1git reflog
2# a1b2c3d HEAD@{0}: reset: moving to HEAD~1
3# e4f5g6h HEAD@{1}: commit: Revert "Add payment processing"
4# a1b2c3d HEAD@{2}: commit: Add payment processing
5
6# Restore the lost commit
7git reset --hard e4f5g6h

The reflog retains entries for at least 30 days by default, so you have a generous window to recover from mistakes.

Choosing the Right Method

The decision depends on a single question - has the revert been pushed to a shared branch?

1Has the revert been pushed?
2  |
3  +-- YES --> Revert the revert (git revert <revert-hash>)
4  |
5  +-- NO ---> Has more work been committed after the revert?
6                |
7                +-- YES --> Interactive rebase to drop the revert
8                |
9                +-- NO ---> git reset --hard HEAD~1

When in doubt, reverting the revert is always safe. It adds a commit to history, but it never disrupts other developers.

Common Pitfalls

• Using git reset on pushed commits - Resetting commits that others have pulled creates divergent histories, forcing teammates to resolve confusing conflicts or re-clone the repository.
• Confusing revert with reset - git revert creates a new commit that undoes changes. git reset moves the branch pointer backward. Using the wrong command leads to unexpected results.
• Forgetting to push after reverting the revert - The fix only exists locally until you push. Team members continue working with the reverted code until the revert-of-revert reaches the remote.
• Ignoring merge conflicts during revert-of-revert - If code has changed since the original commit, the revert-of-revert may conflict. Skipping careful conflict resolution can introduce bugs.
• Not communicating with the team - Reverting and re-reverting on shared branches without notifying collaborators causes confusion. Always inform the team when manipulating shared history.

Summary

• Revert the revert commit with git revert <hash> when the revert has already been pushed to a shared branch. This is the safest approach.
• Use git reset --hard HEAD~1 to erase an unpushed revert commit cleanly, as if it never happened.
• Use interactive rebase to drop a revert commit when it sits among other unpushed local commits you want to keep.
• The git reflog command is your safety net for recovering commits lost during a reset.
• Always prefer adding new commits over rewriting history on shared branches to avoid disrupting collaborators.
• Communicate with your team whenever you revert or undo a revert on a shared branch.