Branch (Versionskontrolle)

An einem Softwareprojekt arbeiten oft viele Leute gleichzeitig an denselben Dateien. Damit sich niemand gegenseitig die Arbeit überschreibt, verwendet man Programme, die jede Änderung mitschreiben und alte Stände aufbewahren. Das bekannteste davon heißt Git. In solchen Programmen kann man den aktuellen Stand des Projekts abzweigen und in dieser Abzweigung weiterarbeiten. Genau diese Abzweigung nennt man Branch, auf Deutsch Zweig. Der ursprüngliche Stand bleibt dabei unangetastet, egal wie viel im Zweig verändert oder kaputtgemacht wird.

Warum Teams nicht alle im selben Stand arbeiten

Ohne Zweige müsste jede Änderung sofort in die Version wandern, die alle benutzen. Eine halbfertige Funktion würde dann das gesamte Projekt lahmlegen. Ein Team von zwanzig Entwicklern würde sich ständig gegenseitig blockieren. Mit Branches arbeitet jeder in seiner eigenen Abzweigung und stört niemanden.

Ein zweiter Grund ist Sicherheit. Wenn ein Experiment schiefgeht, löscht man einfach den Zweig. Der Hauptstand hat davon nie etwas mitbekommen. Diese Möglichkeit, folgenlos etwas auszuprobieren, verändert die Arbeitsweise stark: Man traut sich größere Umbauten zu, weil ein Rückweg garantiert existiert.

Drittens erlauben Branches, mehrere Versionen parallel zu pflegen. Ein Unternehmen kann in einem Zweig an Version 3.0 arbeiten und in einem anderen noch Fehler in Version 2.0 beheben, die Kunden gerade einsetzen. Beide Stände existieren nebeneinander, ohne sich zu vermischen.

Abzweigen, arbeiten, zusammenführen

Ein Versionskontrollsystem speichert die Projektgeschichte als Kette von Speicherpunkten. Jeder solche Punkt heißt Commit und hält fest, welche Zeilen wann von wem geändert wurden. Ein Branch ist im Kern nur ein Zeiger auf einen dieser Punkte. Deshalb geht das Anlegen eines Zweigs praktisch ohne Zeitverlust: Es wird nichts kopiert, es entsteht nur ein neuer Zeiger.

Arbeitet man im Zweig weiter, hängen sich dort neue Commits an, und die Geschichte gabelt sich. Danach folgt das Zusammenführen, im Fachjargon Merge. Das System vergleicht beide Entwicklungslinien und baut die Änderungen zu einem gemeinsamen Stand zusammen. Solange verschiedene Dateien betroffen sind, läuft das automatisch.

Schwierig wird es, wenn zwei Leute dieselbe Zeile unterschiedlich geändert haben. Das nennt man Konflikt, und dann muss ein Mensch entscheiden, welche Fassung gilt. Ein verbreiteter Irrtum ist, dass solche Konflikte ein Fehler des Systems seien. Tatsächlich ist es umgekehrt: Das System erkennt zuverlässig, dass es die Entscheidung nicht selbst treffen darf. Je länger ein Zweig vom Hauptstand getrennt bleibt, desto größer werden die Unterschiede und desto mühsamer der Merge.

Branches in Github-Projekten und KI-Werkzeugen

Wer auf Plattformen wie GitHub oder GitLab ein Projekt anschaut, sieht meist einen Hauptzweig namens main und daneben eine Liste weiterer Zweige. Typische Namen sind feature/login oder bugfix/absturz-beim-start. Der übliche Ablauf: abzweigen, Funktion bauen, Änderung zur Prüfung einreichen, nach Freigabe zurück in main verschmelzen. Diese Einreichung heißt Pull Request und ist der Ort, an dem Kollegen den Code kommentieren.

Auch außerhalb der Programmierung taucht das Prinzip auf. Bei KI-Modellen spricht man von einem Fork oder Zweig, wenn jemand ein veröffentlichtes Modell nimmt und in eine eigene Richtung weiterentwickelt. Assistenzsysteme, die selbstständig Code schreiben, legen für ihre Vorschläge oft automatisch einen eigenen Branch an. So bleibt der geprüfte Stand geschützt, bis ein Mensch den Vorschlag freigibt.

In Wirtschaftsmeldungen begegnet einem der Begriff selten direkt, wohl aber seine Folgen. Wenn es heißt, ein Unternehmen habe eine Software abgespalten oder ein Open-Source-Projekt sei in zwei Lager zerfallen, steckt technisch fast immer ein Zweig dahinter, der nie wieder zusammengeführt wurde.