Skip to content
Log in
← Statistics glossary

revert

Also called: reverted, reverting

A new commit that undoes an earlier one. History keeps both, so nothing is erased. GitHub offers a `Revert` button on merged pull requests.

A revert undoes a change by adding a new commit that does the opposite: lines that were added are removed, lines that were removed come back. The original commit stays in history, so nobody's copy breaks and anyone can see what was undone and why. That makes it the safe way to undo something already on main. On GitHub a merged pull request has a Revert button, which prepares a new pull request with the undo for review.

Example

A spring-sale banner went live with the wrong dates. Sofia clicks Revert on its pull request, the undo is approved and merged, and the banner is gone while history keeps both steps.

Common mistakes

Expecting a revert to take out only part of a change. It undoes the whole commit; if the pull request held two changes and one of them was fine, a small fix forward may be better.

Learn it in the course

  • Your first change in the browser, and how to undo it · Make a small change entirely in the GitHub web UI: find the file, edit it, commit to a new branch because main is protected, open a pull request, pass checks and review, merge and deploy. Then undo a merged change with the Revert button, learn when to revert and when to fix forward, and what a PM should and shouldn't edit.
  • Branches: parallel versions of the project · What a branch is, why work happens on short-lived branches next to main, and how to read branches on GitHub: the branch selector, ahead and behind, stale branches and graphs with several lanes.
  • GitHub flow: small branches, fast merges · The loop most product teams work in: branch from main, pull request, review and checks, merge, deploy. Why small, short-lived branches are safer, what "merged" and "deployed" mean, how feature flags let unfinished work ship hidden, and how to read a feature's progress from the pull request list.
  • Releases and versions: tags, SemVer, changelogs · What a tag is, how to read a version number like v1.4.1 (SemVer in plain words), how GitHub Releases and generated release notes work, how to check whether a fix is in a version, and why merged, released and live for every user can be three different moments.
  • Merging: merge commit, squash and rebase on GitHub · What merging does, the three options behind GitHub's merge button and what each leaves in the history, fast-forward in plain words, and how to check whether a change is really in main.