Feature Branch Workflow in Git

 

Die Grundidee hinter dem Feature Branch Workflow ist, dass die gesamte Feature-Entwicklung in einem dedizierten Branch und nicht in einem 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-Requests, 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. Oder wenn du mitten in der Feature-Entwicklung nicht mehr weiterweißt, kannst du einen Pull-Request starten, um deine Kollegen um Vorschläge zu bitten. Tatsächlichen machen Pull-Requests es deinem Team unglaublich einfach, die Arbeit der anderen zu kommentieren.

Der Git Feature Branch Workflow ist ein zusammenstellbarer Workflow, bei dem andere übergeordnete Git-Workflows genutzt werden können. 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 orientierungsgebendes Framework zum Management und Erstellen von Branches. Andere Workflows sind mehr auf das Repository ausgerichtet. Der Git Feature Branch Workflow kann in andere Workflows integriert werden. Der Git-flow und die Git Forking Workflows nutzen herkömmlicherweise bezüglich ihrer Branching-Modelle einen Git Feature Branch Workflow.

Wie es funktioniert


Der Feature Branch Workflow nutzt 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 pullen und die lokale Repository-Kopie des Master Branches mit der neuesten Version aktualisieren.

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 der Flag -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 einen Pull-Request in einer Repository-Managementlösung wie Bitbucket Cloud oder Bitbucket Server erstellen. Hier kannst du Reviewer hinzufügen und vor dem Mergen einen letzten Blick auf den Code werfen.

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 im Pull-Request.

Pull-Request mergen

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

Pull-Requests

Mithilfe von Branches kann man neben der Isolierung der Feature-Entwicklung auch Änderungen anhand von Pull-Requests 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 einen Pull Request 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 Requests. Sie sind jedoch eigentlich dafür gedacht, damit ihr euch über Code austauschen könnt. Du kannst dir Pull Requests 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 einen Pull Request senden. Interessierte werden dann automatisch benachrichtigt und können die Frage direkt neben den entsprechenden Commits sehen.

Sobald ein Pull-Request 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-Requests vereinfachen. Lies dir dazu die Beispiele in der Dokumentation zu Pull-Requests 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 einem Pull-Request 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 wie nötig erstellen:

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 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-Branches 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 einen Pull-Request 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 den Pull-Request 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-Requests 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 den Pull-Request 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 den Pull-Request 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 im Pull Request 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 im Pull-Request angezeigt.

Mary veröffentlicht ihr Feature

Feature Branch Workflow: Einen Feature Branch mergen

Sobald Bill bereit ist, den Pull Request 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-Requests, 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, den Pull-Request 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 ihrem Pull-Request 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.

Summary


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 der Git-Forking-Workflow und der Git-flow-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 Code-Beispiel und einem fiktiven Beispiel veranschaulicht. Das sind einige der wichtigsten Zusammenhänge rund um den Feature Branch Workflow:

  • Fokus auf Branching-Mustern
  • In anderen Repository-orientierten Workflows nutzbar
  • Stärkere Team-Zusammenarbeit durch Pull-Requests und Merge-Reviews

Führst du git rebase während der Review- oder Merge-Phase eines Feature Branches aus, 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 Team-Umgebung zu fördern.

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

Du möchtest mit Git arbeiten?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen