Version control is an essential part of modern software development, and Git stands as one of the most widely used systems for managing source code. However, even experienced developers occasionally make mistakes—whether by committing buggy code, including unintended files, or pushing incomplete work. Understanding how to revert a commit in Git is a critical skill that allows developers to correct errors safely and efficiently without disrupting collaboration.
TLDR: Reverting a commit in Git allows developers to undo changes while preserving project history. The most common method is git revert, which creates a new commit that reverses previous changes. For local or unpushed commits, commands like git reset can modify or remove commits entirely. Choosing the correct method depends on whether the commit has been shared and how much history needs to be preserved.
In this guide, readers will learn the differences between reverting and resetting, when to use each approach, and step-by-step instructions for common scenarios. Mastering these commands ensures safe collaboration and clean version control workflows.
Understanding What It Means to Revert a Commit
Before diving into commands, it helps to clarify what “reverting” actually means in Git. Reverting does not erase history. Instead, it creates a new commit that undoes the changes introduced by a previous one. This approach preserves the integrity of the project history, which is particularly important in shared repositories.
By contrast, some commands rewrite history entirely. While this may be acceptable in local environments, it can create conflicts or confusion in team settings.
Developers should first determine:
- Has the commit been pushed to a shared repository?
- Does project history need to remain intact?
- Is only one commit affected or multiple?
The answers to these questions influence which Git command is appropriate.
Using git revert (The Safe Option)
The safest way to undo a commit—especially in shared branches—is by using git revert. This command creates a new commit that reverses the changes made in a previous one.
Step-by-Step: Reverting a Single Commit
- Identify the commit hash using:
git log
- Copy the hash of the commit to revert.
- Execute:
git revert <commit-hash>
Git will open a commit message editor, allowing the developer to modify the default reversal message. After saving and closing, a new commit is created that undoes the selected changes.
Key Advantage: History is preserved, and team members can clearly see both the original commit and its reversal.
Reverting Multiple Commits
To revert multiple commits, developers can:
- Revert them individually in sequence, or
- Use a commit range.
Example:
git revert HEAD~3..HEAD
This command reverts the last three commits.
In complex scenarios, merge conflicts may occur. Git will prompt the user to resolve conflicts manually before completing the revert process.
Using git reset (Rewriting History)
While git revert adds a new undo commit, git reset moves the branch pointer backward, effectively removing commits from history. This approach should be used cautiously, particularly if changes have already been pushed.
Types of Git Reset
Git reset has three primary modes:
- –soft
- –mixed (default)
- –hard
1. Soft Reset
git reset –soft HEAD~1
This moves the branch pointer one commit back but keeps changes staged. It is ideal when the developer wants to amend or recommit changes.
2. Mixed Reset
git reset –mixed HEAD~1
This removes the commit and unstages the changes while preserving them in the working directory.
3. Hard Reset
git reset –hard HEAD~1
This erases the commit and permanently removes changes from both staging and working directories. It should only be used when the developer is certain that the changes are no longer needed.
Warning: Never use git reset –hard on commits that have already been pushed unless absolutely necessary and coordinated with the team.
Reverting a Merge Commit
Merge commits require special handling. When reverting a merge, Git must know which parent to treat as the mainline branch.
Example:
git revert -m 1 <merge-commit-hash>
The -m option specifies the parent number (usually 1 for the base branch). Without this argument, Git will not know how to construct the reversal.
Reverting merges can become complex if subsequent commits depend on the merged changes. In such cases, testing the branch thoroughly after the revert is essential.
Reverting a Commit After Push
If a problematic commit has already been pushed to a shared repository, developers should use git revert rather than git reset.
This ensures:
- No history is erased
- No force-push is required
- Collaboration remains stable
Force-pushing after a reset can overwrite remote history, potentially deleting teammates’ contributions. Teams often restrict force pushes to protected branches for this reason.
Reverting vs Resetting: Comparison Chart
| Feature | git revert | git reset |
|---|---|---|
| Preserves History | Yes | No |
| Safe for Shared Branches | Yes | No (without force push) |
| Creates New Commit | Yes | No |
| Best for Local Cleanup | Less common | Yes |
| Risk of Data Loss | Low | High (with –hard) |
Common Scenarios and Solutions
Undoing the Last Commit (Not Pushed)
If the commit has not yet been pushed:
git reset –soft HEAD~1
This allows modifications before recommitting.
Fixing a Commit Message
Instead of reverting, developers can amend:
git commit –amend
This modifies the most recent commit without creating a new one.
Recovering from a Hard Reset
Accidentally used –hard? Git’s reflog may help:
git reflog
The reflog displays previous HEAD states, enabling restoration via:
git reset –hard <reflog-hash>
This can recover seemingly lost commits.
Best Practices When Reverting Commits
- Prefer git revert in shared branches.
- Avoid force pushing unless coordinated.
- Review commit history before executing destructive commands.
- Create backups or tags before major history rewrites.
- Test thoroughly after reverting critical changes.
Adhering to these practices reduces risk and maintains a stable development workflow.
Conclusion
Reverting a commit in Git is not about erasing mistakes—it is about correcting them responsibly. Whether using git revert to maintain shared history or git reset for local cleanup, developers must understand the implications of each command. Choosing the correct method depends largely on whether the branch is shared and how much history integrity matters.
By mastering both revert and reset techniques, teams can work confidently, knowing that mistakes are recoverable and collaboration remains intact. Git’s flexibility ensures that no error is truly permanent—provided the right tools are used thoughtfully.
Frequently Asked Questions (FAQ)
1. What is the safest way to revert a commit in Git?
The safest method is git revert, as it creates a new commit that undoes the previous one without deleting project history.
2. What is the difference between git revert and git reset?
git revert adds a new commit that reverses changes, while git reset rewrites history by moving the branch pointer backward.
3. Can a reverted commit be restored?
Yes. Since revert creates a new commit, developers can simply revert the revert commit if they choose to reapply the changes.
4. Is it safe to use git reset on a shared branch?
No. Using git reset on shared branches requires force pushing, which can disrupt team workflows and overwrite others’ work.
5. How can a developer see past commits?
By running git log to view commit history or git reflog to see recent HEAD movements, including resets.
6. What happens if there is a conflict during git revert?
Git pauses the operation and prompts the developer to resolve the conflict manually before completing the revert commit.
7. Can multiple commits be reverted at once?
Yes. Developers can revert a range of commits using a command like git revert HEAD~3..HEAD, or revert commits individually in sequence.
