Git Revert - Safely Undo Changes

Imagine this scenario: your team deployed code on Friday afternoon, and by Saturday morning users are reporting a critical bug. The problematic commit has already been pushed, pulled by teammates, and deployed to production. You cannot simply delete that commit from history because your entire team's work is built on top of it. This is exactly where git revert saves the day.

git revert creates a new commit that perfectly undoes the changes introduced by a previous commit. It does not erase history or rewrite anything. Instead, it says "I acknowledge what happened, and here is a new commit that reverses it." Your Git log tells the complete story: what was done, and what was undone.

Basic Revert Operation

After running this, your log shows both the original commit and the revert commit:

This is the beauty of revert. Anyone looking at the history immediately understands what happened and why.

Reverting the Most Recent Commit

The most common case is undoing whatever was just committed:

Revert Without Committing

Sometimes you want to stage the revert changes but not commit them immediately. This is useful when you want to revert multiple commits and combine the undos into a single commit:

The --no-commit flag (or -n for short) applies the reversal to your working directory and staging area without creating a commit, giving you full control over the final result.

Reverting Multiple Commits

When you need to undo a range of commits:

For a cleaner history when reverting multiple commits:

Handling Conflicts During Revert

Reverting is not always clean. If code has changed since the original commit, conflicts can arise:

Revert vs Reset: The Critical Difference

This is one of the most important distinctions in Git and a frequent interview question:

The simple rule: if the commit exists only on your local machine, you can use either. If it has been pushed to a shared branch, always use git revert.

Reverting a Merge Commit

Merge commits are special because they have two parents. You must tell Git which parent to revert toward:

This is a tricky operation. When you revert a merge, the changes from the merged branch are undone, but Git remembers the merge happened. If you later want to re-merge that branch, you need to revert the revert first:

Real-World Emergency Workflow

Here is how a production hotfix typically works using revert:

Common Mistakes

Mistake 1: Using git reset on shared branches instead of git revert. This rewrites history that others depend on and causes major synchronization problems across the team.

Mistake 2: Forgetting the -m flag when reverting merge commits. Git will tell you it cannot determine which parent to revert against.

Mistake 3: Trying to re-merge a branch after reverting its merge. You must revert the revert commit first, otherwise Git thinks those changes are already incorporated.

Interview Questions

Q1: When should you use git revert instead of git reset?

Use revert whenever commits have been pushed to a shared branch. Revert creates a new commit preserving history, so teammates are not affected. Reset rewrites history and requires force push, which breaks everyone else's local repository. Only use reset for local unpushed commits.

Q2: How does git revert handle merge commits?

Merge commits have two parents, so you must specify which parent side to keep with the -m flag. -m 1 keeps the mainline parent (undoes the merged branch changes). This is the most common case. Be aware that re-merging the same branch later requires reverting the revert first.

Q3: What happens when a revert creates conflicts?

Conflicts arise when the codebase has changed since the original commit. You resolve them the same way as merge conflicts: edit the files, remove conflict markers, stage with git add, then run git revert --continue. You can abort with git revert --abort if needed.

Q4: Can you revert a revert?

Yes, reverting a revert re-introduces the original changes. This is actually the recommended way to "un-revert" code. It creates a clean history showing that changes were removed, then later re-introduced, with full traceability.

Q5: How does your team handle emergency production rollbacks?

We identify the problematic commit, revert it on main, push immediately to trigger deployment of the fix. The revert is fast and safe. Then we create a branch to properly fix the issue, revert the revert, apply the fix, and merge through normal PR process.