Git-Workflows: Der Feature-Branch-Workflow (Teil 1)

Für Teams, die Git als verteilte Versionskontrolle adaptieren wollen, ist es oft problematisch, den richtigen Einstiegspunkt für die Implementierung zu finden. Wir beschreiben in mehreren Artikeln die am häufigsten genutzten Git-Workflows in Enterprise-Settings und zeigen einige Möglichkeiten auf, Aspekte verschiedener Workflows zu vermengen und anzupassen, um individuelle Anforderungen des Entwicklungsteams abzudecken. Nach dem zentralisierten Workflow, der den Subversion-Prozess auf die Git-Entwicklung überträgt, kommen wir nun zum deutlich flexibleren Feature-Branch-Workflow.

Der Feature-Branch-Workflow

Hat ein Entwicklungsteam den zentralisierten Git-Workflow einmal adaptiert, ist es nicht schwer, Feature-Branches in den Entwicklungsprozess zu integrieren, um die Zusammenarbeit zu intensivieren und die Kommunikation zwischen den Entwicklern zu straffen.

Die Kernidee hinter dem Feature-Branch-Workflow ist die, dass die Feature-Entwicklung in dedizierten Branches stattfinden sollte und nicht im Master-Branch. Diese Abkapselung macht es einfach, mit mehreren Entwicklern an einem bestimmten Feature zu arbeiten, ohne die Haupt-Codebasis zu beeinflussen. Und das bedeutet auch, dass der Master-Branch niemals fehlerhaften Code enthalten wird – in Continuous-Integration-Umgebungen ein enormer Vorteil.

Das Abkapseln der Feature-Entwicklung macht es zudem möglich, Pull-Requests wirksam einzusetzen, die eine ausgezeichnete Möglichkeit bieten, Diskussionen im Hinblick auf den Branch zu initiieren. Sie geben anderen Entwicklern die Chance, ein Feature "abzusegnen", bevor es in das offizielle Projekt integriert wird. Oder ein Entwickler, der mitten in einem Feature festhängt, kann einen Pull-Request stellen, um sich Rat und Ideen von Kollegen zu holen. Kurzum: Pull-Requests machen es wirklich einfach, die Arbeit eines anderen im Team zu kommentieren.

Feature-Branches

Auch der Feature-Branch-Workflow nutzt ein zentrales Repository, der Master repräsentiert auch hier die offizielle Projekt-History. Doch statt direkt in den lokalen Master-Branch zu committen, erzeugen Entwickler jedes Mal, wenn sie mit einem neuen Feature beginnen, neue Branches. (Feature-Branches sollten daher aussagefähige Namen wie objekte-animiertes-menue oder vorgang-#1034 haben, damit für jeden Branch klar ersichtlich ist, welchen Zweck er hat.)

Git macht keine technischen Unterscheidungen zwischen dem Master-Branch und Feature-Branches: Entwickler können editieren, stagen und Änderungen in einen Feature-Branch committen, wie es sie es vom zentralisierten Workflow kennen.

Zusätzlich können (und sollten) Feature-Branches in das zentrale Repository gepusht werden. Dadurch ist es möglich, ein Feature mit anderen Entwicklern zu teilen, ohne irgendwelchen offiziellen Code zu berühren. Da der Master der einzige "spezielle" Branch ist, wirft das Speichern diverser Features im zentralen Repository keinerlei Probleme auf. Natürlich ist das auch ein bequemer Weg, Backups aller lokalen Commits zu erstellen.

Pull-Requests

Abgesehen von der Feature-Entwicklung an sich, ermöglichen es Branches, Änderungen mithilfe von Pull-Requests zu diskutieren. Hat jemand ein Feature fertiggestellt, mergt er es nicht sofort in den Master-Branch. Stattdessen pusht er den Feature-Branch in den zentralen Server und schickt einen Pull-Request mit der Bitte um Anmerkungen in den Master. Das gibt anderen Entwicklern die Möglichkeit, Änderungen gegenzuprüfen, ehe sie Bestandteil der Haupt-Codebasis werden.

Das Reviewen von Code ist ein wesentlicher Vorteil von Pull-Requests, doch in erster Linie sind sie dazu da, einen generischen Weg zu bieten, über Code zu reden. Pull-Requests kann man sich am besten als Diskussionen vorstellen, die sich um einen bestimmten Branch drehen. Sie können also frühzeitig im Entwicklungsprozess genutzt werden, und zwar weit bevor es fertige Features zu reviewen gibt.

Braucht ein Entwickler beispielsweise Unterstützung bei einem bestimmten Feature, muss er einfach nur einen Pull-Request absetzen. Interessierte Kollegen werden automatisch benachrichtigt und können die Frage direkt neben den relevanten Commits einsehen.

Sobald ein Pull-Request akzeptiert wurde, ist der Akt der Veröffentlichung eines Features fast derselbe wie beim zentralisierten Workflow. Der lokale Master muss mit dem Upstream-Master synchronisiert sein, dann wird der Feature-Branch in den Master gemergt und der aktualisierte Master zurück in das zentrale Repository gepusht.

Der zweite Teil dieses Artikels zeigt an einem konkreten Beispiel, wie Entwickler nach dem Feature-Branch-Workflow zusammenarbeiten können.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash von Atlassian? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.

Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

Git und Stash in der Software-Entwicklung: Eine Einführung
Stash in der Praxis
Stash Enterprise: Git-Repository-Management in großen Unternehmen
So funktioniert die Lizenzierung von Atlassian-Produkten

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar