- Developers who already know basic commit and branch actions
- Readers who want to understand command boundaries and risk
Command Reference
git revert Tutorial
Explains why git revert is the safe way to undo shared commits, and how it differs from reset at the history level.
- A basic mental model of worktree, index, and commits
- Comfort reading `git status` and a small commit graph
- Using local cleanup commands on already shared history
- Continuing to rewrite before confirming a recovery path
The short version
git revert does not remove an old commit. Instead, it creates a new commit that reverses the effect of an earlier one.
Why this matters in teams
If a bad commit has already been pushed to a shared branch, rewriting public history with reset can disrupt collaborators. Revert is safer because it preserves the history and records the undo explicitly.
Basic usage
git revert <commit>
Git creates a new commit whose diff cancels the target commit.
Revert several commits
git revert older_commit^..newer_commit
This is useful when a whole sequence needs to be backed out while still preserving the historical record.
Stage the reverse changes without committing yet
git revert --no-commit <commit>
That is useful when you want to combine several reverts into one reviewed commit.
Reverting a merge commit
The official documentation calls out the need to choose a mainline parent:
git revert -m 1 <merge-commit>
Here, -m selects the parent Git should treat as the main line of history.
revert vs reset
revertkeeps history and adds an undo commitresetmoves refs and may rewrite history
As a practical rule, prefer revert when the commit is already shared.
What problem this command solves in a workflow
git revert directly affects history shape, ref position, or relationships between commits. The first decision is whether you are organizing private local history or touching history that is already shared with others.
Typical use cases
- Use
git revertwhen integrating branches, undoing changes, selecting commits, or reshaping a sequence of commits. - Put
git revertinside a “backup first, mutate second, verify last” flow so higher-risk history operations stay recoverable. - Use
git revertto understand ancestry, recovery paths, and commit causality during conflict resolution or post-incident analysis.
Diagram view
Commit sequenceCurrent branchAncestry
New commit relationsMoved refsRecovery path
The highest-value preflight question for this category is simple: “Has this history already been shared?”
Special cases and boundaries
- The most expensive failure mode in history commands is rewriting or moving commits that other people already depend on.
- If the operation might affect team flow, run
git status,git log --oneline --graph, andgit reflogfirst so the recovery path is visible. - When in doubt, create a backup branch before continuing so you preserve an obvious way back.
- Reverting a merge commit usually requires
-mso Git knows which parent should be treated as the mainline.