Hauptgedanke

Der aktuelle Zustand eines Repositorys sagt, was das Produkt heute tut, und sonst nichts. Ein Product Manager, der dort liest, dass ein Export auf fünfzig Zeilen begrenzt ist, erfährt das Verhalten, nicht seinen Grund: Der Code bewahrt keine Spur davon, dass man es mit zweihundert versucht und das dann wegen der Antwortzeiten aufgegeben hat.

Diese Spur gibt es trotzdem, eine Ebene tiefer. Commits, Pull Requests und Merge Requests bilden eine zeitliche Schicht desselben Repositorys: Sie sagen, wie man zum aktuellen Zustand gekommen ist. Eine Diskussion im Code-Review enthält den Einwand eines Entwicklers, den technischen Zwang, der eine Abweichung von der ursprünglichen Anforderung erzwang, den akzeptierten Kompromiss, die Korrektur drei Tage nach der Auslieferung, weil ein Grenzfall aufgetaucht war.

Die nützliche Unterscheidung verläuft also nicht zwischen dem Code und den Dokumenten, sondern zwischen zwei Lesarten desselben Repositorys. Der Zustand beantwortet Verhaltensfragen — welche Regel gilt, wo die Grenze liegt. Die Historie beantwortet Fragen nach dem Grund — warum dieser Wert, warum diese Ablehnung, warum sich dieses Verhalten zwischen März und Juni geändert hat. Das sind zwei verschiedene Quellen, die man unterschiedlich befragt, und wer sie verwechselt, sucht im Zustand, was dort nie stand.

Warum das wichtig ist

Das holt einen Teil dessen zurück, was man verloren glaubte, als man den Code zur Quelle der Wahrheit erklärte. Der übliche Einwand — „Der Code sagt was, nie warum“ — gilt für seinen Zustand, nicht für seine Geschichte; ein Teil der Produktüberlegungen wurde aufgeschrieben, nur nicht dort, wo man sie sucht.

Es verändert auch, was man von einem Code-Review erwartet. Die Kommentare eines Merge Requests sind dann keine Wegwerf-Unterhaltung zwischen zwei Entwicklern mehr: Sie sind der einzige Ort, an dem die tatsächliche Abwägung in dem Moment festgehalten wurde, in dem sie fiel, ohne den Umweg über ein nachträglich verfasstes Dokument.

Nuancen und Grenzen

Die Historie ist nur dann gesprächig, wenn jemand sie zum Sprechen gebracht hat. Ein Repository, dessen Commit-Nachrichten „fix“ lauten und dessen Merge Requests ohne einen einzigen Kommentar gemergt werden, enthält keine Absicht: Die Schicht existiert, aber sie ist leer.

Auch der Ort täuscht. Die ergiebigsten Diskussionen liegen auf der Plattform — GitHub, GitLab — und nicht im geklonten Repository; wird die Historie umgeschrieben, indem man Commits zusammenfasst, verschwindet dabei, was dort festgehalten war.

Schließlich ist eine wiedergefundene Absicht an ihren Zeitpunkt gebunden. Der Grund für eine Wahl vor drei Jahren erklärt diese Wahl; er rechtfertigt nicht die heutige Regel, die seither aus einem ganz anderen Grund neu geschrieben worden sein kann, ohne dass irgendetwas die beiden Zeitpunkte verbindet.

Offene Fragen

• Woran erkennt man, dass eine Diskussion in einem Merge Request es verdient, zur schriftlichen Produktentscheidung erhoben zu werden, statt dort zu bleiben, wo sie festgehalten ist?