How to Undo a Shared Git Commit with git revert

A change that has reached a shared branch is part of the history other people may already have. To reverse one ordinary commit, git revert <commit> applies the opposite change in a new commit; the original commit stays in the log. That makes git revert a practical choice when teammates may already rely on the branch’s existing history. Git’s 2.49.0 revert manual documents this behaviour.

This guide covers one non-merge commit in command-line Git. It assumes you are on the branch that should receive the correction. The examples follow Git’s 2.49.0 manuals, available before 9 June 2025.

Check the branch and choose the exact commit

Start with the branch and working-tree status:

git status --short --branch

Confirm that you are on the intended branch. If the output lists changed or untracked files, pause and preserve any work you need before continuing. Git requires a clean working tree for a normal revert; an existing edit should not be swept away just to make the command run. The git status manual explains the short status format, and the revert manual describes the clean-tree requirement.

Find the commit you intend to reverse:

git log --oneline --decorate -n 10

Copy its hash, then inspect the actual change:

git show --stat --oneline <commit>
git show <commit>

Check the commit message, changed files and patch. A plausible subject line is not enough to identify the right change. git show displays a commit’s message and textual diff, which lets you confirm what the revert will act on. Git’s git-show manual documents the output.

If the header identifies a merge commit with multiple parents, stop here and read the merge section below. This walkthrough uses an ordinary commit.

Create the revert commit

Use the hash you just inspected:

git revert <commit>

Git applies the reverse of that commit’s change and records a new commit. In a terminal, Git normally opens your configured editor with a generated message. Check the message and add a short reason if it would help someone reviewing the history later.

The revert is applied to the branch as it exists now. If later commits changed the same lines, Git may stop for a conflict, or the resulting patch may need review because those later changes depend on the original one. Reverting a commit does not guarantee that the whole project returns to the state it had before that commit.

If Git stops for a conflict

Check which operation and files are involved:

git status

Resolve each file so the result contains the intended current code, then stage only those paths and continue:

git add -- path/to/file
git revert --continue

Repeat for every conflicted file. If you cannot tell what the final code should be, stop and ask the project maintainer to review the change. To cancel the in-progress revert and return to the state before that sequence, run:

git revert --abort

Git documents --continue for a resolved revert and --abort for cancelling the operation in its git-revert manual.

Review the new commit before sharing it

Inspect the new commit and check the repository status:

git show --stat --oneline HEAD
git show HEAD
git status --short --branch

Confirm that the new commit contains the correction you intended and that the branch is still the right one. Run the tests or checks that cover the changed behaviour. A clean status only means there are no remaining reported changes; it does not prove that the application now behaves correctly.

If the original commit was already shared, send the new revert commit through the repository’s normal review process. The original stays in the history and collaborators can receive the corrective commit without replacing the old commit with a different one.

Why git reset is a different operation

Git gives these commands different jobs:

• git revert <commit> records a new commit that reverses an earlier commit’s change.
• git reset <commit> moves the current branch’s HEAD; its mode can also change the index or working tree. In particular, git reset --hard discards tracked working-tree changes that differ from the target commit.
• git restore <path> restores selected file contents from the index or another commit; it does not move the branch pointer.

For a commit that others may already have pulled, preserving the shared history and adding a revert commit is usually easier to coordinate than moving the branch backwards. That recommendation follows from Git’s documented distinction between revert, reset and restore and the effects of git reset. Avoid using git reset --hard as a general-purpose undo command.

A merge commit needs a deliberate parent choice

A merge commit has more than one parent, so Git cannot infer which side should count as the mainline. Reverting it requires git revert -m <parent-number> <commit>. The parent number determines which changes Git reverses, and Git warns that reverting a merge also affects what later merges bring in. Do not add -m 1 by habit: confirm the parent and the intended future merge behaviour with the person responsible for the branch. The revert manual’s mainline section describes this consequence.

For a shared, ordinary commit, the useful checkpoint is simple: identify the exact change, start from a clean working tree on the correct branch, create one revert commit, then review and test that new commit before sharing it.

Sources

These official Git manuals are pinned to version 2.49.0. Git’s manual index dates that version to 14 March 2025, before this article’s 9 June 2025 publication date.

• Git 2.49.0 manual index
• git-revert
• git-status
• git-log
• git-show
• git-reset