A visual summary explaining the main topic of this post: Git revert vs reset: How to Safely Undo a Commit

The Problem

While managing a project with Git, you often realize that a specific commit introduced a problem. For example, you might have committed code that causes a bug, or included a wrong file, and already pushed it to the remote repository.

In such cases, you want to safely remove the changes from that commit. However, forcibly altering the project’s history can be dangerous, especially on a shared branch where other team members are working. Using commands like git reset on a public branch is strongly discouraged.

The Solution: Using git revert

git revert is a command that creates a new commit that applies the inverse of the changes introduced by a specific commit. In other words, instead of deleting or altering the existing commit history, it adds a new commit that undoes the problematic one.

This approach has significant advantages:

  • It’s Safe: It preserves the existing commit history, avoiding conflicts for your teammates.
  • It’s Clear: It leaves a clear and explicit record that a specific commit was undone.

How to Use git revert

  1. Identify the Commit to Revert

    First, use git log to view the commit history and find the hash of the commit you want to undo.

    git log --oneline
# c4a2f85 (HEAD -> main) feat: Add user profile feature
# a1b3c4d fix: Correct login validation
# f9e8d7c chore: Update documentation

    Let’s assume the commit a1b3c4d is the one causing issues.

  2. Run git revert

    Use the following command to revert that commit:

    git revert a1b3c4d

  3. Write the Commit Message

    After you run the command, Git will open a text editor for you to write a commit message for the new “revert” commit. By default, it will generate a message like “Revert “fix: Correct login validation””.

    You can add more details explaining why this commit is being reverted. Once you save the message and close the editor, the new commit will be created.

    If you want to skip editing the commit message, you can use the --no-edit option.

    git revert --no-edit a1b3c4d

  4. Push to the Remote Repository

    Once the revert commit is created locally, push this change to the remote repository to share it with your team.

    git push origin main

Now, if you check the git log again, you will see that the original commits are still there, and a new “Revert” commit has been added on top.

git log --oneline
# 3d5e6f7 (HEAD -> main) Revert "fix: Correct login validation"
# c4a2f85 feat: Add user profile feature
# a1b3c4d fix: Correct login validation
# f9e8d7c chore: Update documentation

git revert vs. git reset

Feature git revert git reset
Action Creates a new commit that undoes changes. Moves the HEAD pointer to a previous commit.
History Preserves the existing history (safe). Alters/deletes the existing history (risky).
Primary Use Case Reverting commits on a shared branch (e.g., main, develop). Cleaning up commits on a private, local branch that hasn’t been shared.

Because git reset erases commit history, using it on a commit that has already been shared with your team can cause serious conflicts with their work. Therefore, on shared branches, you should always use git revert.

Conclusion

git revert is a powerful and essential tool for safely undoing changes that have already been committed, especially those shared on a remote repository.

  • When you need to undo a problematic commit, use git revert <commit-hash>.
  • This command creates a new commit that reverses the changes, rather than rewriting history.
  • As a rule, use git revert instead of git reset on any shared branch.

Fixing mistakes is a natural part of the development process. Use git revert correctly to keep your project’s history clean and safe.

Professional Depth Check

For Git revert vs reset: How to Safely Undo a Commit, the practical standard is not whether the reader can repeat one instruction once. Treat the topic as a reproducible debugging procedure: verify repository root, branch and remote state, index and working tree, and credential or network boundary before drawing a conclusion. The result should be written as a small decision record, because future readers need to know which fact was observed, which assumption was used, and which condition would change the answer.

Evidence That Makes the Guidance Reliable

Use objective evidence before changing a workflow. Good evidence includes git status, git remote -v, git branch --show-current, and the exact command that failed. If two pieces of evidence conflict, keep the conflict visible instead of smoothing it over. For example, a successful quick fix is still weak evidence if the same input, account, dependency, or device state has not been tested again. A durable article should help the reader distinguish a confirmed fix from a plausible fix.

Review Table

Review Item What To Confirm Why It Matters
Scope The exact case covered by this article Prevents over-applying the advice
Baseline The state before any change Makes rollback and comparison possible
Change The smallest action taken Reduces hidden side effects
Result The observed output after the change Separates evidence from expectation
Recheck When to revisit the conclusion Keeps the post accurate over time

Edge Cases and Failure Modes

The main risks are fixing the symptom while leaving the root cause, and mixing unrelated changes into the same test. When the situation involves production data, personal information, money, health, legal rights, or security recovery, the conservative path is to stop and collect evidence before applying a broad fix. The same title can describe very different cases, so the reader should compare their environment with the assumptions in the post before copying commands or decisions.

Continue with these related posts from the same topic area.

Leave a comment

You may also enjoy