How to Safely Revert Commits in Git: A Basic Guidelines for Developers

Learn how to use Git revert to safely undo commits without rewriting history. This guide covers single and multiple commit reversions, merge commits, and best practices for collaborative workflows.

You push a commit, and a minute later you see it: the wrong file, a broken feature, a secret you never meant to share. Now three teammates have already pulled it. Deleting the commit would rewrite history under their feet and break their clones. So you don’t delete it. You revert it.

git revert undoes a commit by adding a new commit that reverses its changes. Your history stays intact, which is exactly what you want on a branch other people share. In this guide we’ll revert a single commit, a range of commits, and the trickiest case of all, a merge commit.

Table of Contents

• Introduction to Git Revert
• Why Use Git Revert?
• Basic Reversion: Undoing a Single Commit
• Reverting Multiple Commits
• Reverting Merge Commits
• Best Practices for Reverting Commits
• Conclusion

Introduction to Git Revert

git revert reverses the changes from a specific commit by recording a new commit that applies the inverse. The original commit stays in the log. That’s the whole point: nothing already published gets rewritten. Compare that to git reset, which moves the branch pointer and drops history. Reset is fine on work only you have. Once a commit is shared, revert is the safe move.

Why Use Git Revert?

On a shared branch like main or develop, other people have already based work on the current history. Rewriting that history with git reset or git rebase forces everyone to reconcile their local copies, and it’s a reliable way to lose someone’s work. git revert sidesteps all of it. It moves forward by adding a commit, so everyone else just pulls one more change like any other.

Basic Reversion: Undoing a Single Commit

The common case is one bad commit. First, find its hash:

# View the commit history
git log --oneline

Then revert it:

# Revert a single commit
git revert <commit-hash>

Git creates a new commit that undoes that commit’s changes and opens your editor with a pre-filled message naming the reverted commit. Keep it or edit it, then save. Done.

Handling Conflicts

If the same lines have changed since the target commit, the revert can conflict, just like a merge. Git pauses and marks the files so you can fix them by hand. Once they’re resolved and staged, finish the revert:

# Continue revert after resolving conflicts
git revert --continue

Changed your mind mid-conflict? git revert --abort puts you back where you started.

Reverting Multiple Commits

Pushed several bad commits? Revert the whole range in one command:

# Revert multiple commits
git revert <oldest-commit-hash>^..<newest-commit-hash>

The ^ after the oldest hash includes that commit in the range. Git creates a separate revert commit for each one, newest first. That’s handy when a run of commits introduced the problem and you want each reversal recorded on its own.

Inspecting Reverted Changes

Want to confirm a revert did what you expected? Inspect it:

# View changes from the revert
git show <revert-commit-hash>

This prints the diff the revert introduced, so you can check the bad change is actually gone before you push.

Reverting Merge Commits

Merge commits are the tricky case, because they have two parents and Git can’t guess which side you want to keep. You tell it with -m, the mainline parent number:

# Revert a merge commit
git revert -m 1 <merge-commit-hash>

-m 1 means “keep the first parent.” For a feature branch merged into main, the first parent is main, so this undoes the merged-in changes while keeping the branch you were on. One honest caveat: reverting a merge records the branch as merged in Git’s eyes. If you later fix that branch and want to merge it again, you’ll need to revert the revert first, or Git will skip the commits it thinks are already in. Worth knowing before you reach for this one.

Best Practices for Reverting Commits

• Tell your team first. A revert changes what’s on the shared branch. A quick heads-up saves someone the confusion of wondering where their feature went.
• Write a message that explains why. The default message says what was reverted. Add the reason, so the next person reading the log isn’t guessing.
• Test after reverting. Undoing one change can expose or reintroduce another. Run the suite before you push.
• Revert, don’t reset, on shared branches. git reset rewrites history and breaks everyone else’s clone. On anything published, revert is the only safe tool.

Conclusion

Reverting is the calm answer to a bad push. Because git revert moves forward instead of erasing the past, you can fix a mistake on a shared branch without stepping on anyone’s work. Single commit, a range, or a merge, the same idea holds: add a commit that undoes the damage, and let history stay honest.