Skip to content
Log in
← 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 revert it · Make a small change entirely in the GitHub web UI: find the file, edit it in the GitHub web editor, 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 GitHub's Revert button, learn when to revert and when to fix forward, and what a PM should and shouldn't edit.
  • Git branches: parallel versions of the project · What a Git 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, naming conventions 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.
  • GitHub releases and versions: tags, SemVer, changelogs · What a git 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 release notes differ from a changelog, 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 on GitHub: merge commit, squash and merge, rebase · What merging does, the three options behind GitHub's merge button (merge commit, squash and merge, rebase and merge) and what each leaves in the history, a fast-forward merge in plain words, and how to check whether a change is really in main.