Feature Branch Workflow in Git

 

Die Grundidee hinter dem Feature Branch Workflow ist, dass die gesamte Feature-Entwicklung in einem dedizierten Branch und nicht im Master Branch stattfinden sollte. Diese Einkapselung erleichtert mehreren Entwicklern die Arbeit an einem bestimmten Feature, ohne dabei die Haupt-Codebasis zu stören. Außerdem wird der Master Branch dadurch niemals beschädigten Code enthalten, was für Continuous Integration-Umgebungen ein immenser Vorteil ist.

Die Einkapselung der Feature-Entwicklung ermöglicht außerdem die Nutzung von Pull-Anfragen, die ein guter Einstiegspunkt für Diskussionen um Branches sind. Andere Entwickler haben dadurch die Möglichkeit, ein Feature zu genehmigen, bevor es in das offizielle Projekt integriert wird. Auch wenn du mitten in der Feature-Entwicklung nicht mehr weiterweißt, kannst du eine Pull-Anfrage starten, um deine Kollegen um Vorschläge zu bitten. Tatsächlich machen es Pull-Anfragen deinem Team unglaublich einfach, die Arbeit der anderen zu kommentieren.

Der Git Feature Branch Workflow ist ein zusammenstellbarer Workflow, der von anderen übergeordneten Git-Workflows genutzt werden kann. Auf der Übersichtsseite zu den Git-Workflows haben wir die anderen Git-Workflows besprochen. Der Git Feature Branch Workflow ist auf das Branching-Modell ausgerichtet, d. h. er ist ein Orientierungsrahmen für die Verwaltung und Erstellung von Branches. Andere Workflows sind mehr auf das Repository ausgerichtet. Der Git Feature Branch Workflow kann in andere Workflows integriert werden. Die Gitflow- und Forking-Workflows nutzen herkömmlicherweise einen Git Feature Branch Workflow für ihre Branching-Modelle.

Wie es funktioniert


Der Feature Branch Workflow übernimmt ein zentrales Repository und Master steht für den Verlauf des offiziellen Projekts. Aber anstatt direkt auf ihrem lokalen Master Branch zu committen, erstellen Entwickler jedes Mal einen neuen Branch, wenn sie an einem neuen Feature arbeiten. Feature Branches sollten beschreibende Namen haben, wie animierte-menü-objekte oder issue-#1061. Dadurch soll jedem Branch ein klarer, deutlich fokussierter Zweck zugewiesen werden. Git unterscheidet rein technisch nicht zwischen dem Master Branch und Feature Branches, deshalb können Entwickler Änderungen am Feature Branch bearbeiten, stagen und committen.
 

Darüber hinaus können (und sollten) Feature Branches auf das zentrale Repository gepusht werden. Dadurch kann ein Feature mit anderen Entwicklern geteilt werden, ohne dass ein offizieller Code davon berührt wird. Da der Master der einzige "besondere" Branch ist, stellt das Speichern mehrerer Feature Branches auf dem zentralen Repository kein Problem dar. Natürlich ist dies auch eine praktische Methode, um die lokalen Commits aller Teammitglieder zu sichern. Im Folgenden geben wir einen Überblick über den Lebenszyklus eines Feature Branches.

Beginne mit dem Master Branch

Alle Feature Branches werden auf Basis des aktuellen Codestatus eines Projekts erstellt. In diesem Leitfaden wird vorausgesetzt, dass das Projekt im Master Branch geführt und aktualisiert wird.

git checkout master
git fetch origin
git reset --hard origin/master

So kannst du vom Repository zum Master Branch wechseln, die neuesten Commits abrufen und die lokale Repository-Kopie des Master Branches auf die neueste Version setzen.

Einen neuen Branch erstellen

Verwende für jedes Feature oder Issue, an dem du arbeitest, einen separaten Branch. Nachdem du einen Branch erstellt hast. checkst du ihn lokal aus, damit alle deine Änderungen auf diesem Branch stattfinden.

git checkout -b new-feature

Dadurch wird ein Branch namens new-feature auf Basis des Master Branches ausgecheckt und die Option -b weist Git an, den Branch zu erstellen, sofern es ihn noch nicht gibt.

Aktualisieren, Hinzufügen, Committen und Pushen von Änderungen

Auf diesem Branch kannst du Änderungen wie gewohnt bearbeiten, stagen und committen und das Feature mit so vielen Commits wie nötig erstellen. Genau wie mit Git kannst du an Features arbeiten und Commits durchführen. Wenn du fertig bist, pushe deine Commits und der Feature Branch in Bitbucket wird aktualisiert.

git status
git add <some-file>
git commit

Feature Branch zu Remote pushen

Es ist immer empfehlenswert, deinen Feature Branch in das zentrale Repository zu pushen. So schaffst du dir ein praktisches Backup und gibst auch anderen Entwicklern, mit denen du zusammenarbeitest, die Möglichkeit, Commits zu diesem neuen Branch zu sehen.

git push -u origin new-feature

Mit diesem Befehl wird new-feature zum zentralen Repository (origin) gepusht und die Option -u fügt es als Remote-Tracking-Branch hinzu. Nach dem Einrichten des Tracking Branches kannst du mit git push den Branch new-feature ohne jegliche Parameter automatisch in das zentrale Repository pushen. Um Feedback zum neuen Feature Branch zu erhalten, kannst du eine Pull-Anfrage in einer Repository-Managementlösung wie Bitbucket Cloud oder Bitbucket Server erstellen. Hier kannst du Reviewer hinzufügen und vor dem Mergen nochmal alles kontrollieren.

Einarbeiten von Feedback

Jetzt kommentieren und genehmigen deine Teamkollegen die gepushten Commits. Bearbeite ihre Kommentare lokal und committe und pushe die vorgeschlagenen Änderungen zu Bitbucket. Deine Updates erscheinen dann in der Pull-Anfrage.

Pull-Request mergen

Vor dem Mergen musst du eventuelle Merge-Konflikte lösen, falls andere Entwickler Änderungen an dem Repository vorgenommen haben. Wenn deine Pull-Anfrage genehmigt wurde und es keine Konflikte gibt, kannst du deinen Code zum Master Branch hinzufügen. Führe das Mergen ausgehend von der Pull-Anfrage in Bitbucket durch.

Pull-Requests

Mithilfe von Branches kann man neben der Isolierung der Feature-Entwicklung auch Änderungen anhand von Pull-Anfragen diskutieren. Sobald ein Teammitglied ein Feature fertiggestellt hat, wird dieses nicht sofort in den Master gemergt. Stattdessen pusht das Teammitglied den Feature Branch zum zentralen Server, erstellt eine Pull-Anfrage und bittet darum, dass die Ergänzungen in den Master gemergt werden. Dadurch erhalten andere Entwickler Gelegenheit, die Änderungen zu überprüfen, bevor sie Teil der Haupt-Codebasis werden.

Code-Review ist ein großer Vorteil von Pull-Anfragen. Sie sind jedoch eigentlich dafür gedacht, dass ihr euch über Code austauschen könnt. Du kannst dir Pull-Anfragen als Diskussion über einen bestimmten Branch vorstellen. Das bedeutet auch, dass sie zu einem viel früheren Zeitpunkt im Entwicklungsprozess genutzt werden können. Wenn ein Entwickler beispielsweise bei einem bestimmten Feature Hilfe braucht, muss er nur eine Pull-Anfragen senden. Interessierte werden dann automatisch benachrichtigt und können die Frage direkt neben den entsprechenden Commits sehen.

Sobald eine Pull-Anfrage akzeptiert wird, läuft die tatsächliche Veröffentlichung eines Features ähnlich ab wie beim zentralisierten Workflow. Zunächst musst du sicherstellen, dass dein lokaler Master mit dem Upstream-Master synchronisiert ist. Dann mergst du den Feature Branch in den Master und pushst den aktualisierten Master zurück zum zentralen Repository.

Managementlösungen für Produkt-Repositorys, wie Bitbucket Cloud oder Bitbucket Server, können Pull-Anfragen vereinfachen. Lies dir dazu die Beispiele in der Dokumentation zu Pull-Anfragen für Bitbucket Server durch.

Beispiel

Im folgenden Beispiel zeigen wir ein Szenario, in dem ein Feature Branch Workflow zum Einsatz kommt. Hier führt ein Team einen Code-Review zu einer Pull-Anfrage eines neuen Features durch. Das ist nur einer von vielen Zwecken, für die sich dieses Modell eignet.

Mary beginnt mit einem neuen Feature

Feature Branch Workflow: Änderungen committen

Bevor sie mit der Entwicklung eines Features beginnt, braucht Mary einen isolierten Branch, an dem sie arbeiten kann. Sie kann mit dem folgenden Befehl einen neuen Branch anfordern:

git checkout -b marys-feature master

Dadurch wird ein Branch namens marys-feature auf Basis des Master ausgecheckt und die Option -b weist Git an, den Branch zu erstellen, sofern er noch nicht vorhanden ist. Auf diesem Branch kann Mary Änderungen wie gewohnt bearbeiten, stagen und committen und ihr Feature mit so vielen Commits erstellen wie nötig:

git status
git add <some-file>
git commit

Mary macht Mittagspause

Feature Branch Workflow: git push

Mary fügt ihrem Feature am Vormittag einige Commits hinzu. Bevor sie zum Mittagessen geht, sollte sie ihren Feature Branch zum zentralen Repository pushen. Dies ist ein praktisches Backup. Sollte Mary außerdem mit anderen Entwicklern zusammengearbeitet haben, hätten diese jetzt auch Zugriff auf ihre ersten Commits.

git push -u origin marys-feature

Mit diesem Befehl wird marys-feature zum zentralen Repository (origin) gepusht und die Option -u fügt es als Remote-Tracking-Branch hinzu. Nach dem Einrichten des Tracking-Branch kann Mary git push ohne jegliche Parameter zum Pushen ihres Features aufrufen.

Mary schließt ihr Feature ab

Feature Branch Workflow: Git push

Wenn Mary vom Mittagessen zurückkommt, stellt sie ihr Feature fertig. Bevor sie es in den Master mergt, muss sie eine Pull-Anfrage erstellen und den Rest des Teams darüber informieren, dass sie fertig ist. Zunächst sollte sie aber sicherstellen, dass das zentrale Repository ihre neuesten Commits enthält:

git push

Dann erstellt sie die Pull-Anfrage in ihrer Git-GUI und bittet darum, marys-feature in den Master zu mergen. Die Teammitglieder werden darüber automatisch benachrichtigt. Das Tolle an Pull-Anfragen ist, dass gleich neben den zugehörigen Commits Kommentare angezeigt werden, deshalb können ganz einfach Fragen zu spezifischen Changesets gestellt werden.

Bill erhält den Pull Request

Feature Branch Workflow: Einen Pull-Request reviewen

Bill erhält die Pull-Anfrage und sieht sich marys-feature an. Er möchte einige Änderungen daran vornehmen, bevor er es in das offizielle Projekt integriert, und er und Mary tauschen sich ein wenig über die Pull-Anfrage aus.

Mary macht Änderungen

Feature Branch Workflow: Überarbeitungen von Pull-Requests

Um Änderungen vorzunehmen, durchläuft Mary genau denselben Prozess, den sie auch zum Erstellen der ersten Iteration ihres Features genutzt hat. Sie bearbeitet, führt Verschiebungen auf die Staging-Ebene durch, committet und verschiebt Aktualisierungen in das zentrale Repository. Alles, was sie tut, wird in der Pull-Anfrage angezeigt. Bill kann währenddessen weiter Kommentare machen.

Wenn Bill wollte, könnte er marys-feature in sein lokales Repository pullen und selbst daran arbeiten. Commits, die er hinzugefügt hat, würden ebenfalls in der Pull-Anfrage angezeigt.

Mary veröffentlicht ihr Feature

Feature Branch Workflow: Einen Feature Branch mergen

Sobald Bill bereit ist, die Pull-Anfrage zu akzeptieren, muss das Feature in das stabile Projekt gemergt werden (entweder Bill oder Mary können das tun):

git checkout master
git pull
git pull origin marys-feature
git push

Dieser Prozess führt häufig zu einem Merge-Commit. Einigen Entwicklern gefällt das, weil es wie eine symbolische Zusammenführung des Features mit dem Rest der Codebasis ist. Wenn dir ein linearer Verlauf eher liegt, ist es möglich, das Feature vor dem Mergen an die Spitze des Master zu verschieben, was zu einem Fast-Forward-Merge führt.

Einige GUIs automatisieren den Genehmigungsprozess von Pull-Anfrage, indem alle diese Befehle einfach durch Klicken auf die Schaltfläche "Akzeptieren" ausgeführt werden. Wenn deine das nicht tut, sollte sie zumindest in der Lage sein, die Pull-Anfrage automatisch abzuschließen, wenn der Feature Branch in den Master Branch gemergt wird.

Währenddessen macht John genau dasselbe

Während Mary und Bill an marys-feature arbeiten und diese Arbeit in ihrer Pull-Anfrage besprechen, tut John genau dasselbe mit seinem eigenen Feature Branch. Indem er Features in einzelnen Branches isoliert, kann jeder unabhängig arbeiten. Trotzdem können Änderungen bei Bedarf weiterhin ganz einfach mit anderen Entwicklern geteilt werden.

Zusammenfassung


In diesem Tutorial haben wir den Feature Branch Workflow in Git behandelt. Mit diesem Workflow können Branches, die auf Business-Features ausgerichtet sind, besser organisiert und nachverfolgt werden. Bei anderen Git-Workflows, wie dem Forking-Workflow und dem Gitflow-Workflow, steht das Repository im Mittelpunkt. Beim Managen dieser Branching-Modelle kannst du den Feature Branch Workflow in Git nutzen. Wir haben hier die Implementierung des Feature Branch Workflows in Git mit einem kurzen Codebeispiel und einem fiktiven Beispiel veranschaulicht. Das sind einige der wichtigsten Zusammenhänge rund um den Feature Branch Workflow:

  • Fokussiert sich auf Branching-Muster
  • Kann von anderen Repository-orientierten Workflows genutzt werden
  • Unterstützt die Zusammenarbeit mit Teammitgliedern durch Pull-Anfragen und Merge-Reviews

Wenn du git rebase während der Review- oder Merge-Phase eines Feature Branches ausführst, wird für Feature-Merges ein zusammenhängender Git-Verlauf erzwungen. Das Feature Branching-Modell eignet sich sehr gut, um die engere Zusammenarbeit in einer Teamumgebung zu fördern.

Steige mit unserem umfassenden Tutorial zum Gitflow-Workflow noch tiefer in Git-Workflows ein.

Möchtest du Git kennenlernen?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen