Sometimes, you'll make a commit and later realize it introduced a bug or contained changes you didn't intend to keep. While you learned about git commit --amend for fixing the very last commit, what if the problematic commit is further back in your history? Deleting or rewriting history that might already be shared with others can cause problems. Git provides a safer way to undo changes from previous commits: git revert.

Unlike commands that alter existing history (like git reset, which we'll discuss elsewhere, or git commit --amend), git revert doesn't delete anything. Instead, it figures out the changes introduced by a specific commit and creates a new commit that does the exact opposite. This new "revert commit" effectively undoes the changes from the original commit while preserving the project's history. Because it adds a new commit rather than rewriting the past, it's safe to use even on branches that have already been shared with collaborators.

How git revert Works

Think of it like adding an entry in an accounting ledger to correct a previous mistake. You don't erase the original incorrect entry; you add a new one that reverses its effect.

When you run git revert <commit-hash>, Git performs these steps:

It examines the specified commit (<commit-hash>) to identify the changes it introduced compared to its parent commit.
It calculates the inverse changes needed to undo the original commit's effects.
It applies these inverse changes to your current working directory and stages them.
It creates a new commit with these inverse changes. By default, Git automatically generates a commit message like "Revert '[Original Commit Subject]'" and opens your configured text editor, allowing you to modify the message before the revert commit is finalized.

Performing a Revert

Let's say your commit history looks like this (simplified):

a1b2c3d Add feature Y
e4f5g6h Fix bug in feature X
i7j8k9l Initial project setup

You realize that the commit e4f5g6h ("Fix bug in feature X") actually introduced another subtle bug. You want to undo the changes made in that specific commit.

You would use the following command:

git revert e4f5g6h

Git will then:

Calculate how to reverse the changes made in e4f5g6h.
Apply these reversals.

Open your editor with a pre-filled message, perhaps:

Revert "Fix bug in feature X"

This reverts commit e4f5g6h1j2k3l4m5n6o7p8q9r0s1t2u3v4w5x6y7z8.

After you save and close the editor, Git creates a new commit.

Your history now looks something like this:

This diagram shows how git revert adds a new commit (red) that undoes the changes from commit e4f5g6h, while keeping the original history intact.

If you check your project files, the changes introduced by e4f5g6h will no longer be present. The original commit e4f5g6h still exists in the history, but its effects have been counteracted by the new revert commit.

Revert vs. Reset

It's important to understand the difference between git revert and git reset (which modifies history).

git revert: Creates a new commit to undo changes. Safe for shared history. Preserves the record of both the original change and its undoing.
git reset: Moves the branch pointer, potentially discarding commits. Rewrites history. Generally unsafe for commits already shared with others.

For undoing changes that are part of your public or shared history, git revert is almost always the preferred method. It clearly communicates that a previous change was undone without erasing the historical context.

Potential Conflicts

Just like merging branches, reverting a commit can sometimes lead to conflicts. This happens if later commits have modified the same lines of code that the commit you're reverting also touched. If Git encounters a conflict during a revert, it will stop and tell you which files have conflicts. You'll need to manually edit these files to resolve the conflicting changes, then use git add to mark them as resolved, and finally run git revert --continue to finish the process. (Or git revert --abort to cancel the revert).

Using git revert provides a robust and safe mechanism for correcting mistakes in your project's history without disrupting collaboration or losing valuable context. It's an essential tool for maintaining a clean and understandable commit history.