Git Revert Last Commit: How to Safely Undo a Change in Git

In software development, mistakes are an inevitable part of the process, but how you address them matters, especially in a team.

When working with Git in a shared repository, you don't just want to undo a bad commit; you want to do it safely. This is why I've written, from my experience, an article on git revert.

Instead of erasing history like git reset, git revert creates a new commit that undoes the changes made in a previous one. This approach preserves your commit history.

If you are new to these concepts, take our Git Fundamentals skill track and learn all about repositories and version control.

What Is Git Revert, and How Does It Work?

Think of git revert as Git's way of saying, "Let's undo that safely." When something slips through in a commit — maybe a bug, a typo, or a rushed change — you might be tempted to delete it. But in a shared repo, deleting history can cause more trouble than the original mistake. That's why git revert exists. Instead of erasing the commit, it adds a new one that cancels out the changes.

So, what does git revert do?

• It adds a new commit: As I had mentioned already, rather than wiping anything away, git revert creates a fresh commit that undoes the specific changes from the one you're reverting. This keeps your project history consistent.

• It applies the change immediately: As I have not yet said, as soon as you run the git revert command, the reverted changes show up in your working directory. So you'll see the fix live.

• It doesn't interfere with staging (unless there's a conflict): An additional thing to know: Git handles the revert internally. If everything goes smoothly, there's no need to stage files manually. However, if Git can't figure out how to reverse something (such as in complex merges), it'll ask you to intervene and help.

What Happens After Reverting a Commit

So, you've run git revert. What exactly just happened? Instead of deleting anything, Git creates a new commit that reverses the changes made in the one you targeted. This new commit is added on top of your existing history, which means the original commit remains untouched and fully visible. Nothing is rewritten or removed; instead, Git adds a layer that effectively says, "Undo that." At the same time, the file changes from that reversal are applied immediately to your working directory. You'll see the fix take effect right away, just like any other commit.

This entire process makes git revert the safest way to fix mistakes that have already been pushed to a shared branch. Everyone on the team can see what was changed, what was reverted, and why without any confusion or disruption to ongoing work.

Comparing git revert to git reset

While both git revert and git reset can be used to undo commits, they work in fundamentally different ways. git reset is good for local, private fixes. It lets you clean up messy commits and reset your working directory exactly how you want it. But it comes with a catch: If you've already pushed your work and then used git reset, you can break things for your teammates by altering shared commit history.

On the other hand, git revert is specially designed for shared or public branches. Instead of erasing anything, it creates a new commit that cancels out the changes from an earlier one. This makes it safer in shared projects.

Here’s a side-by-side comparison to make this clearer:

Reverting Multiple Commits

Sometimes, it’s not just one bad commit, you might need to undo a whole series of them. Fortunately, Git allows you to revert multiple commits in a single command using a commit range.

The syntax looks like this:

git revert OLDEST_HASH^..NEWEST_HASH

This tells Git to start from just before the oldest commit (that’s what the ^ is for) and revert each commit up to and including the most recent one. For example:

git revert a1b2c3d^..d4e5f6g

This command will generate separate revert commits for each of the original commits in that range.

Heads up, reverting multiple commits at once can often trigger merge conflicts, especially if those commits touched the same files or lines. Git will attempt to reverse each commit in sequence, but it may require your assistance in resolving overlapping changes.

You can also read more on how Git handles revert operations including trickier cases like merge commits in Git Revert Merge Commit: A Guide With Examples.

Handling Merge Conflicts During Revert

Reverting might sound simple until Git throws you a curveball - a merge conflict. These usually pop up when:

• You're reverting a commit that changed the same lines as other recent commits.
• You’re reverting a merge commit, or a group of commits with overlapping changes.

Git tries its best to reverse the changes cleanly, but if there’s ambiguity, it will pause and ask for your help.

Here’s how to handle it:

git revert HEAD

And, to check which files are conflicted, use:

git status

To manually resolve the conflicts in your code editor, look for <<<<<<<, =======, and >>>>>>> markers.

Here, I'm marking them as resolved:

git add <resolved-file>

Now, I continue the revert:

git revert-- continue

If you change your mind and want to cancel the revert entirely:

git revert --abort

This flow gives you complete control. You can decide whether to proceed with the revert or back out entirely.

If you want to understand how Git keeps track of reference logs during operations like this, check out Git Reflog: Understanding and Using Reference Logs for tips on troubleshooting messy histories.

Exceptional Cases: Reverting Merge Commits

Reverting a regular commit is straightforward, but merge commits are a whole different beast. That's because a merge commit has two or more parents, and Git needs to know which path (or "mainline") it should treat as the base.

To revert a merge commit, you'll need to use the -m flag explicitly.

git revert -m 1 <merge-commit-hash>

Here’s what the -m flag does:

• The -m stands for mainline, and it tells Git which parent commit should be kept.

• 1 typically refers to the first parent, usually the branch you were on when the merge happened.

• 2 refers to the second parent, often the branch that was merged into.

When would you use 1 or 2?

• Use -m 1 if you want to undo the effect of the merged-in changes but keep the work from your main branch.

• Use -m 2 if you want to remove the mainline’s changes but retain the feature or merged branch’s contents. This is rare. Reverting a merge commit is prone to conflicts and often results in a complex mess, especially if follow-up commits depend on it. If you're unsure, try reverting on a test branch first.

Best Practices When Using git revert

To make the most of git revert and avoid the most common mistakes, keep these best practices in mind:

• Verify commit hashes before reverting: Always inspect your commit history using git log or git log-- oneline to ensure you're targeting the correct change. You can brush up on these commands in Foundations of Git or keep the essentials handy with our Git Cheat Sheet.

• Customize your commit message: Don’t settle for Git’s default “Revert” message. Add context—like why you reverted the commit—to help collaborators (and future you) understand the change.

• Communicate when reverting to shared branches: If you're reverting changes on a public branch, such as main or develop, notify your team first. Reverts affect everyone, and it's best to coordinate. Learn more about collaborative workflows in our GitHub Concepts and Intermediate GitHub Concepts courses.

• Avoid reverting a revert unless you're sure: Reverting a previous revert can bring back unintended changes or cause conflicts. If you need to reapply a change, consider using git cherry-pick instead.

• Use reflog to recover if things go sideways: Made a mistake mid-revert? Use git reflog to view your recent actions and recover lost states.

Conclusion

If you're collaborating in a professional setting, git revert to the last commit using git revert HEAD helps maintain transparency while reducing the risk of accidental data loss. Whether you're cleaning up a mistake or rolling back a bug, revert keeps your repo stable and understandable for everyone involved.