Nahezu alle Versionskontrollsysteme unterstützen heute Branches – unabhängige Arbeitsgebiete, die aus einer zentralen Codebasis abgeleitet werden. Je nach Versionskontrollsystem heißt der Haupt-Branch Master, Mainline, Default oder Trunk. Entwickler können eigene Branches aus dem Haupt-Branch erstellen und unabhängig an diesen arbeiten. 

Was spricht dafür, die Mühe des Branchings auf sich zu nehmen?

Durch Branching können Entwicklerteams auf einfache Weise innerhalb einer zentralen Codebasis zusammenarbeiten. Wenn ein Entwickler einen Branch erstellt, erstellt das Versionskontrollsystem eine Kopie der Codebasis zu diesem Zeitpunkt. Änderungen am Branch wirken sich nicht auf andere Entwickler im Team aus. Und das ist auch gut so, weil Features, die sich noch in der Entwicklung befinden, Instabilität erzeugen können. Es würde die Arbeit des Teams stören, wenn die gesamte Arbeit in der Haupt-Branch stattfinden würde. Aber Branches müssen nicht isoliert sein. Entwickler können auch einfache Änderungen von anderen Entwicklern einarbeiten, an Features zusammenarbeiten und sicherstellen, dass ihr eigener Branch nicht zu weit vom Master abweicht.

Profitipp: Branches sind nicht nur für die Arbeit an Features geeignet. Branches können das Team von umfassenden architekturbezogenen Änderungen wie das Aktualisieren von Frameworks oder gemeinsamen Bibliotheken usw. isolieren.

Drei Branching-Strategien für agile Teams

Branching-Modelle werden in einzelnen Teams oft unterschiedlich umgesetzt und sind Thema zahlreicher Debatten in der Software-Community. Eins der vorrangigen Themen ist, wie viel Arbeit in einem Branch verbleiben sollte, bevor er zurück in den Master gemergt wird. 

Release Branching

Das Release Branching basiert auf der Idee, das sich ein Release komplett innerhalb eines Branchs befindet. Das heißt, dass der Release-Manager zu einem späten Zeitpunkt im Entwicklungszyklus einen Branch aus dem Master erstellt (z. B. "Entwicklungs-Branch 1.1"). Alle Änderungen für das Release 1.1 müssen zweimal angewendet werden: einmal für den Branch 1.1 und das zweite Mal für die Master-Codezeile. Das Arbeiten mit zwei Branches bedeutet einen zusätzlichen Aufwand für das Team, bei dem das Mergen an beiden Branches schnell vergessen wird. Release Branches können unhandlich und schwer zu verwalten sein, weil viele Personen am selben Branch arbeiten. Wir hatten alle schon Probleme damit, viele verschiedene Änderungen an einem einzigen Branch zu mergen. Wenn ein Release Branch erforderlich ist, erstelle den Branch möglichst zeitnah zum tatsächlichen Release. 

Warnung: Das Release Branching ist für den Support versionierter Software auf dem Markt sehr wichtig.Ein einziges Produkt verfügt möglicherweise über mehrere Release Branches (z. B. 1.1, 1.2, 2.0), um eine weitere Entwicklung zu unterstützen.Denke daran, dass Änderungen in frühen Versionen (d. h. 1.1) möglicherweise in spätere Release Branches (d. h. 1.2, 2.0) gemergt werden müssen. Weitere Informationen zum Verwalten von Release Branches mit Git findest du im unten erwähnten Webinar.

Feature Branching

Viele agile Teams, die nach einem flexibleren Branching-Modell suchen, sind vom Release Branching auf das Feature Branching umgestiegen. Ein Feature-Branch-Modell bewahrt alle Änderungen für ein bestimmtes Feature in einem Branch auf. Wenn das Feature durch automatisierte Tests vollständig getestet und validiert wurde, wird der Branch in den Master gemergt.

Feature Branches werden oft mit Feature Toggles kombiniert – eine Art "Umschalter", mit denen ein Feature im Produkt aktiviert oder deaktiviert werden kann. Damit kann der Code einfacher im Master bereitgestellt und es kann einfacher gesteuert werden, wann das Feature aktiviert wird. Auf diese Weise kann der Code weit vor dem Zeitpunkt bereitgestellt werden, zu dem das Feature für Endbenutzer zur Verfügung gestellt wird. 

Profitipp: Ein weiterer Vorteil von Feature Flags besteht darin, dass der Code zwar im Build verbleibt, aber inaktiv ist, solange er sich in der Entwicklung befindet. Wenn bei der Aktivierung des Codes etwas schief geht, kann ein Systemadministrator das Feature Flag rückgängig machen und zu einem bekannten funktionierenden Status zurückkehren, statt einen neuen Build bereitstellen zu müssen.

Aufgaben-Branching

Bei Atlassian setzen wir den Fokus auf einen Branch-pro-Aufgabe-Workflow. Jedes Unternehmen hat eine natürliche Methode, in einem Issue Tracker wie Jira Software Arbeit in einzelne Aufgaben aufzuteilen. Vorgänge werden bei diesem Arbeitsteil dann zum zentralen Kontaktpunkt des Teams. Aufgaben-Branching, auch Vorgangs-Branching genannt, verbindet diese Vorgänge direkt mit dem Quellcode. Jeder Vorgang wird in seinen eigenen Branch implementiert und der Vorgangsschlüssel ist in den Branch-Namen integriert. Es ist leicht zu sehen, welcher Code welchen Vorgang implementiert: Du musst nur nach dem Vorgangsschlüssel im Branch-Namen suchen. Durch diese Transparenz ist es einfacher, bestimmte Änderungen am Master oder einem beliebigen älteren Release-Branch vorzunehmen.

Da agile Methoden auf User Storys aufbauen, passen Aufgaben-Branches gut mit der agilen Entwicklung zusammen. Jede User Story (oder Bug-Korrektur) bleibt in einem eigenen Branch, damit leicht ersichtlich ist, welche Vorgänge noch bearbeitet werden und welche für das Release bereit sind. Für einen umfassenden Einblick in das Aufgaben-Branching (das auch als Vorgangs-Branching oder Branch-pro-Vorgang bezeichnet wird) schnapp dir etwas Popcorn und schau dir die unten aufgeführte Webinar-Aufzeichnung an – die zu unseren beliebtesten überhaupt zählt. 

Kommen wir zum bösen Zwillingsbruder des Branchings: dem Mergen

Wir haben alle schon verzweifelt versucht, mehrere Branches in eine vernünftige Lösung zu integrieren. Früher haben zentralisierte Versionskontrollsysteme wie Subversion das Mergen zu einem sehr aufwändigen Vorhaben gemacht. Aber neuere Versionskontrollsysteme wie Git und Mercurial basieren auf einem anderen Ansatz für die Nachverfolgung von Datenversionen, die in verschiedenen Branches existieren.

Mit Git ist Mergen trivial – und ermöglicht uns, die komplette Power von Branching-Workflows zu nutzen.

Branches sind oft kurzlebig, damit sie einfacher zu mergen sind und über die Codebasis hinweg flexibler bleiben. Da Branches als Teil von Continuous Integration (CI) oft und automatisch gemergt werden können und kurzlebige Branches schlicht und einfach weniger Änderungen enthalten, gehört die "Merge-Hölle" für Teams, die Git und Mercurial verwenden, mittlerweile der Vergangenheit an.

Darum ist das Aufgaben-Branching so fantastisch! 

Prüfen, prüfen, prüfen

Ein Versionskontrollsystem kann da das Ergebnis eines Merge-Vorgangs nur begrenzt beeinflussen. Auch automatisierte Tests und Continuous Integration sind wichtig. Mit den meisten CI-Servern können neue Branches automatisch getestet werden, was die Anzahl der "Überraschungen" beim letzten Upstream-Merge deutlich reduziert und dazu beiträgt, den Haupt-Branch stabil zu halten.

Dargestellte Produkte
Jira Software-Logo
Projekt- und Vorgangsnachverfolgung
Bitbucket-Logo
Bitbucket ist DIE Git-Lösung für professionelle Teams.