Stacked Pull Requests

Programmierer arbeiten fast nie allein an einem Programm. Damit niemand ungeprüft am gemeinsamen Code herumschraubt, gibt es ein festes Verfahren. Wer etwas ändern will, reicht seinen Änderungsvorschlag ein, und Kollegen schauen ihn durch, bevor er übernommen wird. So ein eingereichter Vorschlag heißt Pull Request. Bei großen Umbauten wird ein einzelner Vorschlag aber schnell riesig und praktisch unlesbar. Stacked Pull Requests lösen das: Die große Änderung wird in eine Kette kleiner Vorschläge zerlegt, wobei jeder auf dem vorherigen aufbaut. Der Stapel wird von unten nach oben geprüft und übernommen.

Warum niemand 3000 geänderte Zeilen ernsthaft prüft

Die Qualität einer Code-Prüfung sinkt mit ihrer Größe. Bei fünfzig geänderten Zeilen findet ein Kollege Denkfehler und stellt Rückfragen. Bei dreitausend Zeilen liest er quer, nickt und schreibt « sieht gut aus ». Der Prüfschritt existiert dann noch formal, wirkt aber nicht mehr. Untersuchungen in Firmen zeigen recht einheitlich: Ab etwa 400 geänderten Zeilen werden kaum noch Fehler entdeckt.

Der zweite Vorteil ist Zeit. Ohne Stapel muss ein Entwickler warten, bis sein großer Vorschlag geprüft ist, bevor er weiterbauen kann. Solche Wartezeiten dauern oft einen Tag oder länger. Mit einem Stapel legt er den nächsten kleinen Vorschlag einfach obendrauf und arbeitet weiter. Die Prüfungen laufen parallel zur weiteren Arbeit.

Ein Nebeneffekt ist die bessere Nachvollziehbarkeit. Jeder Schritt im Stapel hat einen eigenen Titel und eine eigene Begründung. Wenn ein Jahr später ein Fehler auftaucht, lässt sich genau die eine kleine Änderung finden, die ihn verursacht hat. Bei einem Riesenvorschlag bleibt nur der Hinweis « Modul neu geschrieben ».

Wie die Kette aus Zweigen entsteht

Code wird in Versionsverwaltungen gespeichert, meist mit dem Programm Git. Dort gibt es einen Hauptstand des Programms und daneben Zweige, also Abspaltungen zum Experimentieren. Normalerweise zweigt man vom Hauptstand ab und reicht das Ergebnis als Vorschlag ein. Beim Stapeln zweigt man stattdessen vom eigenen vorherigen Zweig ab. So entsteht eine Kette: Zweig B baut auf A auf, Zweig C auf B.

Jeder Zweig wird als eigener Pull Request eingereicht. Der Prüfer sieht bei jedem nur den Unterschied zum Vorgänger, nicht die Summe aller Änderungen. Übernommen wird von unten: erst A, dann B, dann C. Genau daran liegt auch die Hauptschwierigkeit.

Verlangt ein Prüfer nämlich eine Korrektur im untersten Zweig, verschiebt sich der Boden unter allen darüberliegenden. Die Kette muss neu aufgesetzt werden, was Git « rebase » nennt. Bei acht gestapelten Zweigen ist das von Hand mühsam und fehleranfällig. Deshalb gibt es Hilfsprogramme wie Graphite, Sapling oder git-town, die das Nachziehen automatisch übernehmen.

Von Meta und Google in kleine Teams

Groß geworden ist die Methode bei Meta und Google. Beide arbeiten mit eigenen Werkzeugen, die Stapel von Anfang an vorsehen, und nennen die einzelnen Schritte dort meist « Diffs » statt Pull Requests. Von dort kam die Arbeitsweise über Startups in die breite Entwicklerwelt.

Auf GitHub, der weltweit größten Plattform für gemeinsame Softwareentwicklung, ist das Stapeln nicht direkt eingebaut. Es funktioniert dort, weil man beim Einreichen angeben kann, auf welchen Zweig sich ein Vorschlag bezieht. Diese Lücke ist der Grund, warum es inzwischen Firmen gibt, die Werkzeuge fürs Stapeln verkaufen. Auf Tech-Seiten tauchen Stacked Pull Requests deshalb oft in Meldungen über Entwickler-Werkzeuge und deren Finanzierungsrunden auf.

Ein häufiger Irrtum: Stapeln bedeutet nicht, mehr Code zu schreiben oder schneller zu tippen. Die Menge an Arbeit bleibt gleich, sie wird nur anders portioniert. Und die Methode ist kein Muss. Für eine einzelne Fehlerkorrektur an drei Zeilen wäre ein Stapel schlicht Aufwand ohne Nutzen.