TopolearnIt's the correct way to back out a bad change that others have already pulled.
`git revert <commit>` computes the inverse of a commit's changes and records it as a new commit, by default with a message like Revert "Add caching layer". The original commit stays in history; the branch simply moves forward.
Because nothing is rewritten, revert is safe on main and any branch others use. Compare with git reset, which moves the branch backwards and forces everyone else to deal with commits disappearing.
Useful forms:
git revert HEAD: undo the most recent commit.git revert a1b2c3d e4f5a6b: several commits, each reverted in its own new commit.git revert --no-commit A..B(or-n): apply the inverse of a range to the working tree and index, then commit once.
If later commits changed the same lines, the revert can conflict; resolve it like any other conflict, then git revert --continue (or --abort).
Reverting a merge commit needs -m 1 to say which parent is the mainline you want to keep, usually parent 1 (the branch you merged into). Beware a subtle consequence: Git now considers the feature's commits merged and undone, so merging that branch again later won't re-apply them. To bring the feature back, revert the revert.
In practice, revert is how teams roll back a deployment-breaking change quickly: revert, push, deploy, and fix forward later in a calm follow-up commit.
Example
git log --oneline -4
# e9f0b12 Add caching layer <- broke production
# 3f9a2c1 Fix totals
git revert e9f0b12 --no-edit
# [main 5c7d8e9] Revert "Add caching layer"
git push # normal push, no force needed
# Undo a merge, keeping the mainline (parent 1)
git revert -m 1 b4e7d21
# Bring the feature back later
git revert 5c7d8e9Remember
- Revert adds a new inverse commit; history is not rewritten
- Safe for pushed/shared branches, unlike reset
- Merge commits need -m 1 to choose the mainline parent
Watch out for
- Re-merging a feature branch after reverting its merge and expecting the changes back — revert the revert instead.