Feature Branch Workflow in Git
The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the main
branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the main
branch will never contain broken code, which is a huge advantage for continuous integration environments.
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
The Feature Branch Workflow assumes a central repository, and main
represents the official project history. Instead of committing directly on their local main
branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch. Git makes no technical distinction between the main
branch and feature branches, so developers can edit, stage, and commit changes to a feature branch.
In addition, feature branches can (and should) be pushed to the central repository. This makes it possible to share a feature with other developers without touching any official code. Since main
is the only “special” branch, storing several feature branches on the central repository doesn’t pose any problems. Of course, this is also a convenient way to back up everybody’s local commits. The following is a walk-through of the life-cycle of a feature branch.
Start with the main branch
All feature branches are created off the latest code state of a project. This guide assumes this is maintained and updated in the main
branch.
git checkout main
git fetch origin
git reset --hard origin/main
This switches the repo to the main
branch, pulls the latest commits and resets the repo's local copy of main
to match the latest version.
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
This checks out a branch called new-feature based on main
, and the -b flag tells Git to create the branch if it doesn’t already exist.
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
This command pushes new-feature to the central repository (origin), and the -u flag adds it as a remote tracking branch. After setting up the tracking branch, git push
can be invoked without any parameters to automatically push the new-feature branch to the central repository. To get feedback on the new feature branch, create a pull request in a repository management solution like Bitbucket Cloud or Bitbucket Data Center. From there, you can add reviewers and make sure everything is good to go before merging.
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
Before you merge, you may have to resolve merge conflicts if others have made changes to the repo. When your pull request is approved and conflict-free, you can add your code to the main
branch. Merge from the pull request in Bitbucket.
Pull-Anfragen
Aside from isolating feature development, branches make it possible to discuss changes via pull requests. Once someone completes a feature, they don’t immediately merge it into main
. Instead, they push the feature branch to the central server and file a pull request asking to merge their additions into main
. This gives other developers an opportunity to review the changes before they become a part of the main codebase.
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.
Once a pull request is accepted, the actual act of publishing a feature is much the same as in the Centralized Workflow. First, you need to make sure your local main
is synchronized with the upstream main
. Then, you merge the feature branch into main
and push the updated main
back to the central 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 main
This checks out a branch called marys-feature
based on main,
and the -b flag tells Git to create the branch if it doesn’t already exist. On this branch, Mary edits, stages, and commits changes in the usual fashion, building up her feature with as many commits as necessary:
git status
git add <some-file>
git commit
Mary macht Mittagspause
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
When Mary gets back from lunch, she completes her feature. Before merging it into main
, she needs to file a pull request letting the rest of the team know she's done. But first, she should make sure the central repository has her most recent commits:
git push
Dann 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
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
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 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 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 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:
- 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.