Definition „Branching“ Was ist ein Code Branch?
Von Egoloizos
Anbieter zum Thema
Branches bezeichnen in der Softwareentwicklung beziehungsweise in der Versionsverwaltung bestimmte unabhängige Arbeitsgebiete. Das Branching umfasst auch die Erstellung eigener Branches aus dem Haupt-Branch. Entwickler können an diesen unabhängig arbeiten.
Branching wird heute von nahezu sämtlichen Versionskontrollsystemen unterstützt. Die unabhängigen Arbeitsgebiete lassen sich aus einer zentralen Codebasis ableiten. In Abhängigkeit des jeweils genutzten Versionskontrollsystems sind die Haupt-Branches als Mainline, Default oder Trunk bekannt.
Es existieren unterschiedliche Branching-Strategien, die sich für verschiedene Anwendungsszenarien eignen. Das Branching ist im Zusammenhang mit Teams, speziell der agilen Teambildung von Bedeutung. In der Entwickler-Community ist das Branching Gegenstand zahlreicher Debatten. Eines der meistdiskutierten Themen im Rahmen der Arbeit mit dem Branching ist die Frage, welche und wie viel Arbeit in einem Branch verbleiben soll, bevor er zurück in den Haupt-Branch gelangt.
Branching und Branching-Strategien in Teams
Zu den wichtigsten Branching-Modellen beziehungsweise Branching-Strategien, die in Teams zum Einsatz kommen, gehören das Release-Branching, das Feature-Branching sowie das Aufgaben-Branching.
Gemeinsam ist den Branching-Ansätzen, dass einzelne Entwickler die Möglichkeit haben, an unabhängigen Branches Änderungen vorzunehmen. Hierbei werden zunächst mehrere Aufgabenströme voneinander unabhängig gehalten. Anschließend gibt es die Möglichkeit, die Arbeit wieder zusammenzuführen (Merging). Branching und Merging sind daher meist im Zusammenhang miteinander zu betrachten. Auf diese Weise haben Entwickler die Möglichkeit, zu gewährleisten, dass es im Zuge der Änderungen an jedem Branch zu keinen Konflikten kommt.
Release-Branching
Beim Release-Branching geht es darum, dass sich der Release vollständig innerhalb eines Branchs befindet. Der Release-Manager soll hierbei zu späterer Zeit im Entwicklungszyklus aus dem Haupt-Branch einen neuen Branch erstellen. Dabei kann es sich zum Beispiel um den Entwicklungs-Branch 1.1 handeln. In dieser Vorgehensweise sind sämtliche Änderungen für den ersten Release (1.1) zweimalig anzuwenden: zum einen für den Branch 1.1 und zum anderen für die Haupt-Codezeile.
Die Arbeit mit diesen zwei Branches ist für das Entwickler-Team mit zusätzlichem Aufwand verbunden. Oftmals sind Release-Branches schwer zu handhaben und zu verwalten. Dies hängt damit zusammen, dass oftmals viele Personen an ein und demselben Branch arbeiten. Aus diesem Grund ist es vorteilhaft, den Branch nach Möglichkeit zeitnah am tatsächlichen Release zu erstellen, sobald ein Release-Branch erforderlich ist.
Release-Branching spielt im Zusammenhang mit versionierter Software eine große Rolle auf dem Markt. Dies betrifft im Besonderen den Support für diese Software. In vielen Fällen handelt es sich bei ein und demselben Produkt um mehrere Release-Branches, damit eine nachhaltige Entwicklung begünstigt wird (beispielsweise Releases der Versionen 1.1, 1.2, 1.3, 2.1 und so weiter). Beim Release-Branching ist stets zu berücksichtigen, dass frühere Versionen der Releases gegebenenfalls eines Mergins in spätere Release-Branches bedürfen.
Feature-Branching
Feature-Branches dienen oft dazu, bestimmte Features in Produkten und Software zu aktivieren oder zu deaktivieren. Daher kommen Feature-Branches oft im Zusammenhang mit Feature-Flags zu m Einsatz. Dies trägt dazu bei, dass der Code sich im Haupt-Branch einfacher bereitstellen lässt. Auf diese Weise lässt sich zudem auf einfachere Weise steuern, wann es zur Aktivierung eines Features kommen soll. Die Bereitstellung des Codes erfolgt damit lange vor dem Zeitpunkt, an dem das Feature für Enduser bereitstehen soll.
Feature-Flags haben weiterhin den Vorteil, dass der Code inaktiv bleibt, so lange er sich in der Entwicklung befindet, dabei aber weiterhin im Build verbleibt. Sollte es bei der Code-Aktivierung zu Schwierigkeiten kommen, haben Administratoren die Option, das Feature-Flag rückgängig zu machen. Dabei ist es möglich, zu einem früheren und funktionierenden Status zurückzukehren, ohne dass es der Bereitstellung eines neuen Builds bedarf.
Aufgaben-Branching
Das Aufgaben- oder Vorgangs-Branching verbindet verschiedene Vorgänge unmittelbar mit dem Quellcode. Dabei kommt es zur Implementierung jeden Vorgangs in seinem eigenen Branch. Der Vorgangsschlüssel wird dabei integriert in den Branch-Namen.
Dabei ist einfach ersichtlich, welcher Code welchen Vorgang implementiert: der Vorgangsschlüssel lässt sich im Branch-Namen suchen. Diese Transparenz macht es besonders einfach, Änderungen am Haupt-Branch vorzunehmen. Ebenso sind hierbei Änderungen an nahezu jedem beliebigen älteren Release-Branch möglich.
Aufgaben-Branching oder Task-Branching ist auch im Zusammenhang mit agiler Software-Entwicklung beliebt. Der Vorteil besteht darin, dass jede Änderung, jeder Bugfix und jede User-Story in einem eigenen Branch verbleibt. Damit bleibt es einfach ersichtlich, welche Aufgaben noch zu erledigen sind und welche Vorgänge noch nicht bearbeitet wurden. Ebenso bleiben Vorgänge im Blick, die bereits für einen Release bereit sind.
Vorteile und Stärken des Branchings
Das Branching ermöglicht Beteiligten in der Softwareentwicklung eine vereinfachte Form der Zusammenarbeit innerhalb einer zentralen Codebasis. Die Versionsverwaltung profitiert von dieser Kooperation. Sobald ein Entwickler einen Branch erstellt, kommt es zur Erstellung einer Kopie der jeweiligen Codebasis zum vorliegenden Zeitpunkt. Damit wirken sich Änderungen an dem einen Branchen nicht auf andere Teammitglieder aus.
Dies ist ein Vorteil, da zum Beispiel ein noch in Entwicklung befindliches Feature Instabilität im System auslösen kann. Fände die gesamte Arbeit im Haupt-Branch statt, würde dies die Arbeit des Entwickler-Teams beeinträchtigen. Gleichermaßen müssen Branches beim Branching nicht vollständig isoliert sein. Ebenso können Entwickler gemeinsam an Features zusammenarbeiten und damit gewährleisten, dass es zu keiner zu großen Abweichung des eigenen Branchs zum Haupt-Branch kommt.
Branches bezeichnen in der Softwareentwicklung beziehungsweise in der Versionsverwaltung bestimmte unabhängige Arbeitsgebiete. Das Branching umfasst auch die Erstellung eigener Branches aus dem Haupt-Branch. Entwickler können an diesen unabhängig arbeiten.
Das Branching: Definition und Überblick
Branching wird heute von nahezu sämtlichen Versionskontrollsystemen unterstützt. Die unabhängigen Arbeitsgebiete lassen sich aus einer zentralen Codebasis ableiten. In Abhängigkeit des jeweils genutzten Versionskontrollsystems sind die Haupt-Branches als Mainline, Default oder Trunk bekannt.
Es existieren unterschiedliche Branching-Strategien, die sich für verschiedene Anwendungsszenarien eignen. Das Branching ist im Zusammenhang mit Teams, speziell der agilen Teambildung von Bedeutung. In der Entwickler-Community ist das Branching Gegenstand zahlreicher Debatten. Eines der meistdiskutierten Themen im Rahmen der Arbeit mit dem Branching ist die Frage, welche und wie viel Arbeit in einem Branch verbleiben soll, bevor er zurück in den Haupt-Branch gelangt.
Branching und Branching-Strategien in Teams
Zu den wichtigsten Branching-Modellen beziehungsweise Branching-Strategien, die in Teams zum Einsatz kommen, gehören das Release-Branching, das Feature-Branching sowie das Aufgaben-Branching.
Gemeinsam ist den Branching-Ansätzen, dass einzelne Entwickler die Möglichkeit haben, an unabhängigen Branches Änderungen vorzunehmen. Hierbei werden zunächst mehrere Aufgabenströme voneinander unabhängig gehalten. Anschließend gibt es die Möglichkeit, die Arbeit wieder zusammenzuführen (Merging). Branching und Merging sind daher meist im Zusammenhang miteinander zu betrachten. Auf diese Weise haben Entwickler die Möglichkeit, zu gewährleisten, dass es im Zuge der Änderungen an jedem Branch zu keinen Konflikten kommt.
Release-Branching
Beim Release-Branching geht es darum, dass sich der Release vollständig innerhalb eines Branchs befindet. Der Release-Manager soll hierbei zu späterer Zeit im Entwicklungszyklus aus dem Haupt-Branch einen neuen Branch erstellen. Dabei kann es sich zum Beispiel um den Entwicklungs-Branch 1.1 handeln. In dieser Vorgehensweise sind sämtliche Änderungen für den ersten Release (1.1) zweimalig anzuwenden: zum einen für den Branch 1.1 und zum anderen für die Haupt-Codezeile.
Die Arbeit mit diesen zwei Branches ist für das Entwickler-Team mit zusätzlichem Aufwand verbunden. Oftmals sind Release-Branches schwer zu handhaben und zu verwalten. Dies hängt damit zusammen, dass oftmals viele Personen an ein und demselben Branch arbeiten. Aus diesem Grund ist es vorteilhaft, den Branch nach Möglichkeit zeitnah am tatsächlichen Release zu erstellen, sobald ein Release-Branch erforderlich ist.
Release-Branching spielt im Zusammenhang mit versionierter Software eine große Rolle auf dem Markt. Dies betrifft im Besonderen den Support für diese Software. In vielen Fällen handelt es sich bei ein und demselben Produkt um mehrere Release-Branches, damit eine nachhaltige Entwicklung begünstigt wird (beispielsweise Releases der Versionen 1.1, 1.2, 1.3, 2.1 und so weiter). Beim Release-Branching ist stets zu berücksichtigen, dass frühere Versionen der Releases gegebenenfalls eines Mergins in spätere Release-Branches bedürfen.
Feature-Branching
Feature-Branches dienen oft dazu, bestimmte Features in Produkten und Software zu aktivieren oder zu deaktivieren. Daher kommen Feature-Branches oft im Zusammenhang mit Feature-Flags zu m Einsatz. Dies trägt dazu bei, dass der Code sich im Haupt-Branch einfacher bereitstellen lässt. Auf diese Weise lässt sich zudem auf einfachere Weise steuern, wann es zur Aktivierung eines Features kommen soll. Die Bereitstellung des Codes erfolgt damit lange vor dem Zeitpunkt, an dem das Feature für Enduser bereitstehen soll.
Feature-Flags haben weiterhin den Vorteil, dass der Code inaktiv bleibt, so lange er sich in der Entwicklung befindet, dabei aber weiterhin im Build verbleibt. Sollte es bei der Code-Aktivierung zu Schwierigkeiten kommen, haben Administratoren die Option, das Feature-Flag rückgängig zu machen. Dabei ist es möglich, zu einem früheren und funktionierenden Status zurückzukehren, ohne dass es der Bereitstellung eines neuen Builds bedarf.
Aufgaben-Branching
Das Aufgaben- oder Vorgangs-Branching verbindet verschiedene Vorgänge unmittelbar mit dem Quellcode. Dabei kommt es zur Implementierung jeden Vorgangs in seinem eigenen Branch. Der Vorgangsschlüssel wird dabei integriert in den Branch-Namen.
Dabei ist einfach ersichtlich, welcher Code welchen Vorgang implementiert: der Vorgangsschlüssel lässt sich im Branch-Namen suchen. Diese Transparenz macht es besonders einfach, Änderungen am Haupt-Branch vorzunehmen. Ebenso sind hierbei Änderungen an nahezu jedem beliebigen älteren Release-Branch möglich.
Aufgaben-Branching oder Task-Branching ist auch im Zusammenhang mit agiler Software-Entwicklung beliebt. Der Vorteil besteht darin, dass jede Änderung, jeder Bugfix und jede User-Story in einem eigenen Branch verbleibt. Damit bleibt es einfach ersichtlich, welche Aufgaben noch zu erledigen sind und welche Vorgänge noch nicht bearbeitet wurden. Ebenso bleiben Vorgänge im Blick, die bereits für einen Release bereit sind.
Vorteile und Stärken des Branchings
Das Branching ermöglicht Beteiligten in der Softwareentwicklung eine vereinfachte Form der Zusammenarbeit innerhalb einer zentralen Codebasis. Die Versionsverwaltung profitiert von dieser Kooperation. Sobald ein Entwickler einen Branch erstellt, kommt es zur Erstellung einer Kopie der jeweiligen Codebasis zum vorliegenden Zeitpunkt. Damit wirken sich Änderungen an dem einen Branchen nicht auf andere Teammitglieder aus.
Dies ist ein Vorteil, da zum Beispiel ein noch in Entwicklung befindliches Feature Instabilität im System auslösen kann. Fände die gesamte Arbeit im Haupt-Branch statt, würde dies die Arbeit des Entwickler-Teams beeinträchtigen. Gleichermaßen müssen Branches beim Branching nicht vollständig isoliert sein. Ebenso können Entwickler gemeinsam an Features zusammenarbeiten und damit gewährleisten, dass es zu keiner zu großen Abweichung des eigenen Branchs zum Haupt-Branch kommt.
(ID:48707365)
