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

Im letzten Artikel sind wir auf die Vorteile eingegangen, Feature-Branches in den Entwicklungsprozess mit Git zu integrieren, um die Zusammenarbeit zu intensivieren und die Kommunikation zwischen den Entwicklern zu straffen. Dieser Folgebeitrag bietet ein Beispiel dafür, wie Entwickler nach dem Feature-Branch-Workflow kollaborieren und sich Pull-Requests zunutze machen können.

Entwickler A beginnt ein neues Feature

Git Feature Branch Workflow 1

Ehe Entwickler A mit der Entwicklung eines Features beginnt, braucht er einen isolierten Branch, an dem er arbeiten kann. Der Git-Befehl hat diese Form:

git checkout -b entwickler-a-feature master

Dadurch wird ein Branch namens entwickler-a-feature erzeugt, der auf dem Master-Branch basiert. -b weist Git an, den Branch zu erstellen, sofern er noch nicht existiert. In diesem Branch kann Entwickler A nun wie üblich editieren, stagen und Änderungen committen und sein Feature mit so vielen Commits wie erforderlich bauen:

git status
git add <some-file>
git commit

Entwickler A geht zum Mittagessen

Git Feature-Branch-Workflow 2

Entwickler A fügt seinem Feature im Verlauf des Vormittags ein paar Commits hinzu. Bevor er zum Mittagessen geht, hält er es für eine gute Idee, sein Feature hoch in das zentrale Repository zu pushen. Das ist eine praktische Backup-Möglichkeit, doch wenn A mit anderen Entwicklern zusammenarbeiten würde, bekämen diese damit ebenfalls Zugriff auf seine initialen Commits:

git push -u origin entwickler-a-feature

Der Befehl pusht entwickler-a-feature in das zentrale Repository (origin). -u fügt ihn als einen Remote-Tracking-Branch hinzu. Nach dem Aufsetzen des Tracking-Branchs kann A git push ohne weitere Parameter ausführen, um sein Feature zu pushen.

Entwickler A stellt sein Feature fertig

Git Feature Branch Workflow 3

Nach der Mittagspause stellt A sein Feature fertig. Ehe er es in den Master-Branch mergt, muss er einen Pull-Request stellen, damit der Rest des Teams weiß, dass er soweit ist. Doch zunächst soll sichergestellt sein, dass das zentrale Repository die neuesten Commits hat:

git push

Dann speichert er den Pull-Request mit der Bitte, entwickler-a-feature in den Master zu mergen, in der Git-Oberfläche, und die anderen Teammitglieder erhalten automatische Benachrichtigungen. Das Schöne an Pull-Requests ist, dass sie Kommentare direkt neben dem entsprechenden Commits anzeigen. Es ist also einfach, Fragen zu einem spezifischen Zusammenhang zu stellen.

Entwickler B erhält einen Pull-Request

Git Feature Branch Workflow 4

Entwickler B erhält den Pull-Request und schaut sich entwickler-a-feature an. Er ist der Meinung, dass ein paar Änderungen vorgenommen werden sollten, ehe das Feature ins offizielle Projekt integriert wird; in diesem Zusammenhang haben B und A einen Austausch via Pull-Request.

Entwickler A nimmt Änderungen vor

Git Feature Branch Workflow 5

Um die Änderungen vornzunehmen, folgt Entwickler A exakt demselben Prozess wie bei der ersten Iteration seines Features. Er editiert, stagt, committet und pusht Aktualisierungen in das zentrale Repository. Alles, was er tut, wird im Pull-Request abgebildet, und Entwickler B kann alles kommentieren.

Wenn er wollte, könnte Entwickler B selbst entwickler-a-feature in sein lokales Repository ziehen und seinerseits daran arbeiten. All seine hinzugefügten Commits würden ebenfalls im Pull-Request abgebildet werden.

Entwickler A veröffentlicht sein Feature

Git Feature Branch Workflow 6

Nachdem Entwickler B den Pull-Request akzeptiert hat, muss jemand das Feature in das stabile Projekt mergen. Das können sowohl A oder B tun:

git checkout master
git pull
git pull origin entwickler-a-feature
git push

Zunächst muss, wer immer auch den Merge durchführt, seinen Master-Branch auschecken und sicherstellen, dass er aktuell ist. Dann mergt git pull origin entwickler-a-feature die Kopie von entwickler-a-feature in das zentrale Repository. Dieser Befehl stellt sicher, dass immer die aktuellste Version des Feature-Branchs gemergt wird. Zum Schluss muss der aktualisierte Master zurück nach origin gepusht werden.

Das Ergebnis dieses Prozesses ist oft ein Merge Commit. Einige Entwickler mögen das, denn es ist wie das symbolische Hinzufügen eines Features zum Rest der Codebasis. Doch wenn man eine lineare History bevorzugt, ist es möglich, ein Rebasing des Features an die Spitze des Master-Branchs durchzuführen, bevor der Merge intitiiert wird. Resultat ist ein Fast-Forward-Merge.

Einige Repository-Managementsysteme automatisieren den Prozess, den Pull-Request zu akzeptieren, indem all diese Befehle durch einen einfachen Klick auf einen entsprechenden Akzeptieren-Button ausgelöst werden. Wenn ein System dies nicht unterstützt, sollte es zumindest den Pull-Request schließen, wenn das Feature in den Master gemergt wird.

Derweil macht Entwickler C das gleiche

Während A und B an entwickler-a-feature arbeiten und im Pull-Rquest darüber diskutieren, macht Entwickler C das gleiche mit seinem eigenen Feature-Branch. Durch das Isolieren von Features in separaten Branches kann jeder unabhängig arbeiten – und dennoch ist es simpel, Änderungen wenn nötig mit anderen Entwicklern zu teilen.

Fazit

Teams, die diesen Workflow adaptieren, werden schnell erkennen, wie Feature-Branches die Funktionalitäten des einzelnen Master-Branchs, der im zentralisierten Workflow genutzt wird, multiplizieren. Darüber hinaus fördern Feature-Branches Pull-Requests, die es ermöglichen, spezifische Commits direkt im Repository-Managementsystem zu diskutieren.

Der Feature-Branch-Workflow ist ein wirklich flexibler Weg, um Projekte zu entwickeln. Er kann allerdings auch zu flexibel sein. In großen Teams ist es oft vorteilhaft, verschiedenen Branches spezifischere Rollen zuzuweisen. Hier setzt der Gitflow-Workflow an, dem wir die nächsten Artikel dieser Reihe widmen werden.

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