Feature Branching für großartige Ergebnisse

Oder du findest deinen Weg durch Task-Branching. Oder Release-Branching. Du entscheidest.

Dan Radigan Dan Radigan
Themen durchsuchen

Nahezu alle Versionskontrollsysteme unterstützen heute Branches, das heißt 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 im 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 vor umfassenden architekturbezogenen Änderungen wie dem Aktualisieren von Frameworks oder gemeinsamen Bibliotheken usw. schützen.

Drei Branching-Strategien für agile Teams

Branching-Modelle werden in 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:

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 nachhaltige Entwicklung zu unterstützen. Denke daran, dass Änderungen in frühen Versionen (z. B. 1.1) möglicherweise in spätere Release-Branches (z. . 1.2, 2.0) gemergt werden müssen. Weitere Informationen zum Verwalten von Release-Branches mit Git erhältst du im unten erwähnten Webinar.

Feature Branching

Feature Branches werden oft mit Feature Flags 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 schiefgeht, 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-Task-Workflow. Jedes Unternehmen hat eine geregelte Methode, in einem Vorgangstracker wie Jira Software Aufgaben in einzelne Tasks aufzuteilen. Vorgänge werden bei diesem Aufgabenteil dann zum zentralen Kontaktpunkt des Teams. Task-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 wird in den Branch-Namen aufgenommen. So 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 auf User Storys aufbaut, passen Task-Branches gut zur Agile-Entwicklung. Jede User Story (bzw. jeder Bugfix) bleibt in einem eigenen Branch, damit leicht ersichtlich ist, welche Vorgänge noch bearbeitet werden und welche zum Release bereit sind. Einen umfassenden Einblick in das Task-Branching (das auch als Vorgangs-Branching oder Branch-pro-Vorgang bezeichnet wird) erhältst du in der unten angegebenen Webinar-Aufzeichnung, 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. In den früheren zentralisierten Versionskontrollsystemen wie Subversion war das Mergen sehr aufwendig. Neuere Versionskontrollsysteme wie Git und Mercurial dagegen basieren auf einem anderen Ansatz für die Nachverfolgung von Datenversionen in verschiedenen Branches.

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 Task-Branching so fantastisch!

Prüfen, prüfen, prüfen

Ein Versionskontrollsystem kann 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.

Weiter geht's
Git branching video