AlgoMaster Logo

git revert

Last Updated: January 3, 2026

6 min read

If you’ve ever found yourself in a situation where you needed to undo a commit but wanted to preserve the history, git revert is your go-to tool.

Unlike other commands that alter history, git revert creates a new commit that undoes the changes of a previous commit. This makes it a safe option for collaborative environments, where rewriting history can lead to confusion or lost work.

Understanding how git revert works will empower you to handle mistakes gracefully while keeping your project’s history intact.

What is git revert?

At its core, git revert is a command that takes a commit and produces a new commit that negates the changes introduced by the original commit. This means that instead of deleting the commit from the history, it applies the inverse of the changes, keeping the overall commit history linear and transparent.

When you run git revert, Git creates a new commit that effectively undoes the changes made in the specified commit. This is particularly useful in shared repositories, as it allows team members to see what was changed, why it was reverted, and maintain a clear history.

For example, if you accidentally introduced a bug in your code and committed the change, you can use git revert to create a new commit that reverts the changes made by the buggy commit.

How to use git revert

Using git revert is straightforward, but there are some nuances to understand. The basic command syntax is:

Here, <commit_hash> is the SHA-1 identifier of the commit you want to revert. You can find this identifier with git log.

Example Scenario

Let's say you have the following commit history:

If commit f5e6d8a introduced an issue, you would run:

This creates a new commit that undoes the changes made by f5e6d8a.

Handling Multiple Commits

Sometimes, you may need to revert multiple commits at once. You can achieve this by specifying a range of commits. For example:

This command will revert the last two commits. The HEAD~2..HEAD syntax specifies a range from two commits before the current HEAD to the current HEAD.

Important Consideration

Reverting a range of commits creates multiple new commits. Each commit in the specified range will be reverted individually. This means if any of those revert operations encounter conflicts, you’ll need to resolve them one at a time.

Understanding Merge Commits

Reverting merge commits can be more complex than reverting regular commits. A merge commit combines changes from different branches, making it tricky to revert. When you revert a merge commit, you need to specify which parent commit you want to use as the reference point for the revert.

The command for reverting a merge commit looks like this:

Here, <parent_number> indicates which parent to use. For instance, if you're reverting a merge commit that has two parents, use -m 1 for the first parent or -m 2 for the second.

Example Scenario

Suppose you have a merge commit abc1234 that merged the feature branch into main. If you want to revert that merge and keep the changes from the main branch, you would do:

This operation creates a new commit that undoes the effects of the merge without affecting the history of the feature branch.

Dealing with Conflicts

Just like merging branches, reverting can lead to conflicts, especially when the changes being reverted overlap with newer changes in your codebase. When this happens, Git will pause the revert process and prompt you to resolve the conflicts.

You can follow these steps to resolve conflicts during a revert:

  1. Identify Conflicts: Git will mark the files with conflicts. You can check the status with git status.
  2. Resolve Conflicts: Open the conflicting files and manually edit them to resolve the issues.
  3. Stage Resolved Files: After resolving conflicts, stage the files with:

Continue the Revert: Finally, complete the revert process by running:

Alternatively, if you decide you don’t want to proceed with the revert due to the conflicts, you can abort the revert operation:

Best Practices for Using git revert

Using git revert effectively can save you a lot of headaches. Here are some best practices:

  • Single Responsibility: Each commit should ideally represent a single change. This makes it easier to revert specific commits without affecting unrelated changes.
  • Frequent Commits: Commit often, especially before making major changes. This way, if something goes wrong, you have clear, isolated commits to revert.
  • Clear Commit Messages: Write descriptive commit messages. When you revert a commit, the message should explain why it was reverted, providing context for others.
  • Testing After Reverts: Always run your tests after a revert. Ensure that the revert didn’t introduce new issues.

Real-world Applications of git revert

In practice, git revert is valuable in various scenarios:

  • Collaborative Projects: When working in teams, maintaining a clear history is crucial. Using git revert helps to undo changes without rewriting history.
  • Bug Fixes: If a feature introduces a bug, you can quickly revert the commit while still allowing the rest of the work to continue.
  • Feature Rollback: In cases where a new feature doesn’t perform as expected, you can revert its commit and reassess without losing other progress.

Now that you understand how to safely revert changes using git revert, you are ready to explore git clean, which helps manage untracked files in your working directory.

In the next chapter, we will look at how to clean up your Git environment and remove unwanted files without affecting your committed history.