Revert PR

Software is rarely created by one person alone. Usually, many developers work on a shared body of text, the source code. So that nothing gets mixed up in the process, everyone first formally proposes their change. Such a proposal is called a pull request, or PR for short: a list of lines to be added or removed, plus a justification. Others look at it, comment on it, and approve it before the change is merged into the official version. A revert PR is such a proposal with a special content: it undoes a change that has already been merged and restores the previous state.

Reverting instead of fixing

When a new piece of code causes a bug, there are two paths. One can search for the cause and fix the bug. Or one can undo the change for the time being. The second path is almost always faster. That’s why many teams follow the rule: revert first, then investigate calmly.

The reason is economic. For large services, every minute of disruption costs money and trust. Debugging can take hours, a revert takes minutes. In the best case, the user only notices a brief irregularity. The actual bug is then fixed calmly afterward, and the change is resubmitted later.

The attitude behind it matters. A revert is not a punishment and not a judgment of the person who wrote the code. In well-run projects, it is considered a normal tool, much like deleting a paragraph in a draft text. Where reverts are seen as an embarrassment, teams hesitate too long and the disruption grows bigger.

How the rollback works technically

Software projects store their history in a version control system, usually the program Git. There, every change is stored as its own entry, called a commit. For each commit, it is precisely recorded which lines it removed and which it added. From this information, the counter-movement can be calculated automatically.

That is exactly what the revert command does. It creates a new entry that deletes everything that was added and reinserts everything that was deleted. The original change remains in the project’s history. So nothing is covered up; instead, a correction is appended. From this new entry, an entirely ordinary pull request is then created, which is reviewed and merged.

This only works cleanly if not too much has happened since the change in question. If other developers have since worked on the same lines, a conflict arises and someone has to decide by hand. It becomes even more difficult with changes that have left traces outside the code, for example in a database. A revert restores the program text, not automatically the data.

Reverts in projects and in the news

Revert PRs are most visible in open projects whose development anyone can follow. On platforms like GitHub, they usually carry an automatically generated title that begins with the word Revert and cites the name of the change being undone. Anyone interested in a project can trace there which ideas were discarded again. The discussion below often also states what went wrong.

In news reports, reverts often appear indirectly. When a company announces that an update has been withdrawn or a feature has been temporarily disabled, this process is often technically exactly what is behind it. This has happened several times with AI products, for instance when a provider reverted a new version of its language model because it responded to users in an excessively agreeable manner.

Related but not the same is the feature flag. It allows a finished feature to be switched on and off with a toggle, without changing the code. This is even faster than a revert PR and is therefore preferred for large services. The revert nevertheless remains the more fundamental tool, because it also works where no toggle was provided.