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.