Revert-PR

Software entsteht selten von einer Person allein. Meist arbeiten viele Entwickler an einem gemeinsamen Textbestand, dem Quellcode. Damit dabei nichts durcheinandergerät, schlägt jeder seine Änderung erst einmal förmlich vor. Ein solcher Vorschlag heißt Pull Request, kurz PR: eine Liste von Zeilen, die hinzukommen oder verschwinden sollen, plus eine Begründung. Andere schauen darauf, kommentieren und stimmen zu, bevor die Änderung in die offizielle Fassung übernommen wird. Ein Revert-PR ist ein solcher Vorschlag mit einem besonderen Inhalt: Er nimmt eine bereits übernommene Änderung wieder zurück und stellt den vorherigen Zustand her.

Zurücknehmen statt reparieren

Wenn ein neues Stück Code einen Fehler verursacht, gibt es zwei Wege. Man kann die Ursache suchen und den Fehler beheben. Oder man macht die Änderung erst einmal rückgängig. Der zweite Weg ist fast immer schneller. Deshalb gilt in vielen Teams die Regel: erst zurücknehmen, dann in Ruhe untersuchen.

Der Grund ist wirtschaftlich. Bei großen Diensten kostet jede Minute Störung Geld und Vertrauen. Eine Fehlersuche kann Stunden dauern, ein Revert dauert Minuten. Der Nutzer merkt im besten Fall nur eine kurze Unregelmäßigkeit. Der eigentliche Fehler wird danach in aller Ruhe repariert und die Änderung später erneut eingereicht.

Wichtig ist die Haltung dahinter. Ein Revert ist keine Bestrafung und kein Urteil über die Person, die den Code geschrieben hat. In gut geführten Projekten gilt er als normales Werkzeug, etwa so wie das Löschen eines Absatzes in einem Textentwurf. Wo Reverts als Blamage gelten, zögern Teams zu lange und die Störung wird größer.

Wie die Rückabwicklung technisch abläuft

Softwareprojekte speichern ihre Geschichte in einem Versionsverwaltungssystem, meistens in dem Programm Git. Dort ist jede Änderung als eigener Eintrag gespeichert, ein sogenannter Commit. Zu jedem Commit ist genau festgehalten, welche Zeilen er entfernt und welche er hinzugefügt hat. Aus dieser Information lässt sich automatisch die Gegenbewegung berechnen.

Genau das macht der Befehl zum Zurücknehmen. Er erzeugt einen neuen Eintrag, der alles Hinzugefügte löscht und alles Gelöschte wieder einfügt. Die ursprüngliche Änderung bleibt dabei in der Geschichte des Projekts stehen. Es wird also nichts vertuscht, sondern eine Korrektur angehängt. Aus diesem neuen Eintrag wird dann ein ganz gewöhnlicher Pull Request, der geprüft und übernommen wird.

Sauber funktioniert das nur, wenn seit der fraglichen Änderung nicht zu viel passiert ist. Haben andere Entwickler inzwischen an denselben Zeilen gearbeitet, entsteht ein Konflikt und jemand muss von Hand entscheiden. Noch schwieriger wird es bei Änderungen, die außerhalb des Codes Spuren hinterlassen haben, etwa in einer Datenbank. Ein Revert stellt den Programmtext wieder her, nicht automatisch die Daten.

Reverts in Projekten und in Meldungen

Am sichtbarsten sind Revert-PRs in offenen Projekten, deren Entwicklung jeder mitlesen kann. Auf Plattformen wie GitHub tragen sie meist einen automatisch erzeugten Titel, der mit dem Wort Revert beginnt und den Namen der zurückgenommenen Änderung zitiert. Wer sich für ein Projekt interessiert, kann dort nachvollziehen, welche Ideen wieder verworfen wurden. Häufig steht in der Diskussion darunter auch, was schiefgelaufen ist.

In Nachrichten tauchen Reverts oft indirekt auf. Wenn ein Unternehmen mitteilt, ein Update sei zurückgezogen worden oder eine Funktion vorübergehend abgeschaltet, steckt technisch häufig genau dieser Vorgang dahinter. Bei KI-Produkten kam das mehrfach vor, etwa als ein Anbieter eine neue Version seines Sprachmodells zurücknahm, weil sie den Nutzern übertrieben zustimmend antwortete.

Verwandt, aber nicht dasselbe ist das Feature-Flag. Damit lässt sich eine fertige Funktion per Schalter ein- und ausschalten, ohne den Code zu ändern. Das geht noch schneller als ein Revert-PR und wird deshalb bei großen Diensten bevorzugt. Der Revert bleibt trotzdem das grundlegendere Mittel, weil er auch dort greift, wo kein Schalter vorgesehen wurde.