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 main-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 main-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 funktioniert "git revert"?
Der Feature-Branch-Workflow nutzt ein zentrales Repository und main steht für den Verlauf des offiziellen Projekts. Aber anstatt direkt auf ihrem lokalen main-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-menue-objekte oder issue-#1061. Dadurch soll jedem Branch ein klarer, deutlich fokussierter Zweck zugewiesen werden. Git unterscheidet rein technisch nicht zwischen dem main-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 main-Branch 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.
Mit dem main-Branch beginnen
Alle Feature-Branches werden auf Basis des aktuellen Codestatus eines Projekts erstellt. In diesem Leitfaden wird vorausgesetzt, dass das Projekt im main-Branch geführt und aktualisiert wird.
Zugehöriges Material
Git-Protokoll für Fortgeschrittene
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
git checkout main
git fetch origin
git reset --hard origin/mainSchritt 1: Erstelle das Repository.
So kannst du vom Repository zum main-Branch wechseln, die neuesten Commits pullen und die lokale Repository-Kopie des main-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-featureDadurch wird ein Branch namens "new-feature" auf Basis des main-Branches ausgecheckt und das Flag -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 commitFeature 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-featureMit diesem Befehl wird new-feature zum zentralen Repository (origin) gepusht und das Flag -u fügt es als Remote-Tracking-Branch hinzu. Nach dem Einrichten des Tracking-Branches kannst du den Branch new-feature mit git push 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 Data Center 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 deine Pull-Anfrage genehmigt wurde und es keine Konflikte gibt, kannst du deinen Code zum main-Branch hinzufügen. Führe das Mergen über die Pull-Anfrage in Bitbucket durch.
Pull-Anfragen
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 main-Branch gemergt. Stattdessen pusht das Teammitglied den Feature-Branch zum zentralen Server, erstellt eine Pull-Anfrage und bittet darum, dass die Ergänzungen in den main-Branch 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 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 main-Branch mit dem Upstream-main-Branch synchronisiert ist. Dann mergst du den Feature-Branch in den main-Branch und pushst den aktualisierten main-Branch 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
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 mainDadurch wird ein Branch namens marys-feature auf Basis des main-Branches ausgecheckt und die Option -b weist Git an, den Branch zu erstellen, sofern es ihn noch nicht gibt. 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 commitMary macht Mittagspause
.svg?cdnVersion=1567)
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-featureMit 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
Wenn Mary vom Mittagessen zurückkommt, stellt sie ihr Feature fertig. Bevor sie es in den main-Branch 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 pushDann erstellt sie den Pull-Request in ihrer Git-GUI und bittet darum, marys-feature in den main-Branch 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
.svg?cdnVersion=1567)
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
.svg?cdnVersion=1567)
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
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 main
git pull
git pull origin marys-feature
git pushDieser 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 main-Branch 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 dies bei deiner GUI nicht der Fall ist, sollte sie zumindest in der Lage sein, den Pull-Request automatisch abzuschließen, wenn der Feature-Branch in den main-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.
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 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.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
