Feature-Branch
Ein Feature-Branch ist eine abgetrennte Arbeitskopie eines Software-Projekts, in der genau eine neue Funktion entwickelt wird. Erst wenn sie fertig und geprüft ist, wird die Arbeit mit der Hauptversion des Projekts zusammengeführt.
Programme bestehen aus Textdateien, die viele Menschen gemeinsam bearbeiten. Damit sich dabei niemand in die Quere kommt, verwalten Entwickler ihren Programmtext mit einem Programm, das jede Änderung mitschreibt und ältere Zustände wiederherstellen kann. Ein solches Verwaltungsprogramm kann von einem Projekt mehrere parallele Arbeitsstände führen. Ein Feature-Branch ist so ein paralleler Arbeitsstand, angelegt für eine einzige neue Funktion. Man kopiert also gedanklich das gesamte Projekt, baut in der Kopie zum Beispiel eine Suchfunktion ein und lässt den offiziellen Stand des Projekts unangetastet. Erst wenn die neue Funktion läuft, werden beide Stände wieder vereint.
Warum Teams nicht direkt am Hauptstand arbeiten
Der offizielle Stand eines Projekts heißt meist „main“. Aus ihm wird die Version gebaut, die Kunden benutzen. Er muss deshalb jederzeit funktionieren. Halbfertiger Programmtext würde das gefährden.
Feature-Branches lösen dieses Problem, weil Experimente in einem abgetrennten Bereich stattfinden. Ein Entwickler kann etwas kaputt machen, ohne die Arbeit der Kollegen zu blockieren. Führt eine Idee ins Nichts, wird der Branch einfach gelöscht. Nichts von dem Versuch bleibt im offiziellen Stand zurück.
Ein zweiter Vorteil ist die Kontrolle. Weil alle Änderungen einer Funktion an einem Ort gesammelt sind, kann ein Kollege sie am Ende geschlossen durchlesen. Diese Prüfung nennt man Code Review. Sie ist in vielen Firmen Pflicht, bevor etwas in den Hauptstand darf.
Vom Abzweigen bis zum Zusammenführen
Am Anfang steht das Abzweigen. Der Entwickler nimmt den aktuellen Hauptstand als Ausgangspunkt und gibt dem neuen Branch einen sprechenden Namen, etwa „suche-filter“. Danach arbeitet er nur noch dort. Jede gespeicherte Änderung landet als eigener Schritt in der Historie dieses Branches.
Ist die Funktion fertig, folgt das Zusammenführen, im Fachjargon Merge. Das Verwaltungsprogramm vergleicht beide Stände und übernimmt die neuen Zeilen in den Hauptstand. Meist geht das automatisch. Haben aber zwei Personen dieselbe Zeile unterschiedlich geändert, entsteht ein Konflikt, und ein Mensch muss entscheiden, welche Fassung gilt.
Deshalb gilt eine Faustregel: Feature-Branches sollen klein sein und kurz leben. Wer drei Monate abgetrennt arbeitet, hat am Ende hunderte Konflikte. Viele Teams holen sich darum regelmäßig die neuesten Änderungen aus dem Hauptstand in ihren Branch. So bleibt der Abstand klein, und das Zusammenführen bleibt harmlos.
Pull Requests, GitHub und der Alltag im Entwicklerteam
Das verbreitetste Verwaltungsprogramm für Programmtext heißt Git. Plattformen wie GitHub oder GitLab bauen darauf eine Weboberfläche. Dort stellt man einen Branch als sogenannten Pull Request zur Diskussion. Kollegen kommentieren einzelne Zeilen, verlangen Änderungen und geben ihn irgendwann frei.
Bei Open-Source-Projekten kann man diesen Ablauf öffentlich mitlesen. Wer bei einem freien Programm einen Fehler beheben will, legt einen Feature-Branch an und schickt einen Pull Request. Die Betreuer des Projekts entscheiden dann, ob die Änderung aufgenommen wird. Auf diese Weise entstehen große Teile der Software, die im Internet läuft.
Auch in Wirtschaftsnachrichten taucht das Prinzip auf, wenn es um die Entwicklungsgeschwindigkeit von Tech-Firmen geht. Häufig genannt wird der Gegenentwurf namens Trunk-based Development: Dort arbeiten alle fast direkt am Hauptstand und schalten unfertige Funktionen nur für Nutzer unsichtbar. Beide Ansätze verfolgen dasselbe Ziel, nämlich häufige und risikoarme Auslieferungen. Sie unterscheiden sich nur darin, wie lange Arbeit getrennt vom Rest liegen bleibt.