What it is: git revert is a Git command that undoes the changes introduced by a specific past commit, by creating a brand-new commit that applies the exact opposite of those changes. The original commit is never deleted, hidden, or rewritten — it stays exactly where it was in the project’s history, permanently visible.

Why it exists: Sometimes a change that was committed and shared with others turns out to be wrong, buggy, or simply unwanted — but by the time anyone notices, other people may have already built further work on top of it, or the change may already be running in production. Deleting that commit from history would be dangerous and confusing for everyone who already has a copy of it. git revert exists to undo the effect of the change while leaving the historical record completely intact and honest.

Where it’s used: git revert is the standard tool for undoing changes that have already been shared with others — pushed to a shared branch, merged into main, or deployed. It’s especially common as an emergency response when a bad change reaches production and needs to be undone quickly and safely.

Practical example: A team at an e-commerce company merges a change that updates how shipping costs are calculated. An hour after deployment, customers start reporting incorrect shipping charges. Instead of scrambling to figure out a fix under pressure, an engineer runs git revert on the problematic commit, instantly restoring the previous, working shipping-cost logic, while the team investigates the actual bug calmly, without time pressure.

In the earliest, simplest model of version control, “undoing” a change meant literally deleting or rewriting the record of it — much like using correction fluid on a paper document. This works fine as long as only one person has ever seen that document. But software is almost never that simple: the moment a commit is pushed to a shared repository, other people may have already downloaded it, built new work on top of it, or even deployed it to run in production for real users.

If you tried to simply erase that commit from shared history at that point, you would create a serious mismatch: your copy of history would say the change never happened, while everyone else’s copy — and anyone who already deployed it — would still show it. Reconciling those two different versions of “what happened” is difficult and error-prone, and can silently reintroduce bugs when histories are merged back together.

The core problem revert solves: how do you safely undo a change that other people, or other systems, may already depend on, without rewriting a shared, already-distributed history? Revert answers this by treating “undoing” as just another ordinary, forward-moving change — not a rewrite of the past.

A commit in Git is a saved snapshot of your entire project at one point in time, along with a message describing what changed and why. Each commit also stores a reference to the commit that came directly before it — this is what forms the connected chain we call “history.” Crucially, Git doesn’t usually store a change as “add this, remove that” in the commit itself — it stores full snapshots, but it can efficiently compute the difference (called a “diff”) between any two snapshots whenever needed.

When people talk about “what a commit changed,” they really mean the diff between that commit’s snapshot and its parent commit’s snapshot — the set of lines added, removed, or modified to get from one state to the next. This diff is exactly what git revert needs to compute its opposite.

This snapshot-and-diff relationship is the foundation that makes revert possible: because Git can always calculate exactly what a given commit changed relative to its parent, it can also calculate — and apply — the exact opposite of that change.

flowchart LR
    A["You run: git revert commit-X"] --> B["Git computes the diff introduced by commit-X"]
    B --> C["Git computes the inverse of that diff"]
    C --> D["Git applies the inverse diff to your current files"]
    D --> E{"Applies cleanly?"}
    E -->|Yes| F["Git creates a new commit with the inverse changes"]
    E -->|No, conflict| G["You resolve the conflict manually, then finish the revert"]
    G --> F
    

Step by step, in plain language: first, you tell Git which commit you want to undo the effect of. Second, Git looks at that commit and its parent, and computes exactly what changed between them — the diff. Third, Git calculates the mathematical inverse of that diff: everywhere the original commit added a line, the inverse removes it; everywhere it removed a line, the inverse adds it back; everywhere it modified a line, the inverse changes it back to the original wording. Fourth, Git attempts to apply that inverse diff on top of your current files. Fifth, if your files haven’t changed in a conflicting way since that commit, this applies cleanly and Git automatically creates a brand-new commit containing exactly those inverse changes. If something else has changed the same lines in the meantime, Git pauses and asks you to resolve the conflict by hand, exactly as it would during a conflicting merge — once resolved, you tell Git to continue, and it finishes creating the revert commit.

The resulting new commit typically has a default, auto-generated message such as “Revert ‘<original commit message>'” along with a reference back to the original commit’s identifier, so anyone reading history later can trace exactly which change is being undone and why, if a reason was added.

Notice that at no point in this lifecycle does anyone need to coordinate a special, risky history-rewriting operation across multiple copies of the repository — the revert commit simply flows through the system the same way any ordinary change does.

Git has several commands that can feel like “undo,” but they behave very differently, and mixing them up on shared history can cause real problems. Understanding the distinction is one of the most valuable things a beginner can learn early.

git checkout (or its modern counterpart, git restore) is different again — it doesn’t create any new commit at all. It simply changes the files in your working directory to match some earlier snapshot, without altering the commit history whatsoever. It’s typically used to discard uncommitted edits or temporarily inspect an older version of a file, not to undo something that’s already been committed and shared.

Sometimes an entire sequence of commits — say, five commits that together implemented a feature — needs to be undone at once, not just one. Git allows reverting a range of commits, and it will attempt to apply the inverse of each one, typically working backward from the most recent commit in the range to the oldest, since each commit’s inverse needs to be applied to the state left by undoing the ones after it.

Reverting a whole range of commits is inherently riskier than reverting a single one, because the chance of a conflict rises with each additional commit involved, especially if other, unrelated changes have touched the same files since. It’s also worth knowing that reverting a merge commit — the special kind of commit created when one branch is merged into another — requires telling Git which of the merge’s two parent lines of history should be treated as the “mainline” to revert back toward, since a merge, unlike an ordinary commit, has two parents instead of one.

A conflict during a revert happens for essentially the same reason a conflict happens during a merge: Git’s automatic, line-by-line matching can’t confidently decide how to apply the inverse changes, usually because the same lines of code have been modified again by some later commit. This isn’t a sign that anything is broken — it’s Git correctly recognizing that it needs a human judgment call rather than guessing.

When this happens, Git marks the conflicting sections directly in the affected files, pauses the revert partway through, and waits for you to manually decide what the final content should look like. Once you’ve edited the files to resolve the conflict and marked them as resolved, you tell Git to continue, and it finishes creating the revert commit exactly as it would have if there had been no conflict at all.

The core trade-off to internalize: revert optimizes for safety and honesty of the historical record over a “clean-looking” history with no trace of mistakes. For nearly all shared, collaborative work, that trade-off is exactly the right one — the safety it buys is worth far more than tidiness.

Because a revert commit is an ordinary commit like any other, it should go through the same code review process described in a related guide before being merged into a shared or production branch — even in an urgent incident, a second set of eyes helps confirm the revert actually targets the right commit and doesn’t have unintended side effects.

It’s also worth remembering that reverting a code change does not automatically undo anything that change already caused outside of Git itself — for example, if a buggy commit already sent incorrect data to a customer or modified a database, reverting the code stops the bug from continuing, but doesn’t retroactively fix data that’s already been affected. Those consequences typically need to be handled separately.

The Revert-First-Investigate-Later Pattern treats revert as the immediate, default first response to any change that’s causing problems in a shared or production environment — restore the known-working state fast, then take the time to properly understand and fix the underlying issue without pressure.

The Revert-and-Reopen Pattern pairs the revert commit with reopening the original task or issue that introduced the problem, ensuring the underlying work isn’t simply forgotten once the immediate symptom is undone.

Common anti-patterns to avoid: the Silent Revert (undoing a shared change without any explanation in the commit message or team communication, leaving teammates confused about why something they were relying on disappeared); the Panic Reset (using history-rewriting commands under pressure during an incident, on a branch that’s already shared); and the Un-Reverted Revert (reverting a change temporarily during an emergency but never following up to properly fix or reintroduce the underlying work).

Common mistakes beginners make: confusing revert with reset and accidentally rewriting shared history when they meant to undo a change safely; reverting a large range of commits without expecting or budgeting time for potential conflicts; and forgetting that the auto-generated revert commit message, while accurate, rarely explains the actual reasoning behind the decision to a future reader.