Branching Strategies in Git

Dieser Artikel ist Teil unserer Reihe „Advanced Git“. Folgen Sie uns auf Twitter oder melden Sie sich für unseren Newsletter an, um über die nächsten Artikel informiert zu werden!

Fast alle Versionskontrollsysteme (VCS) unterstützen auf die eine oder andere Weise das Branching. Kurz gesagt, Branching bedeutet, dass Sie die Hauptentwicklungslinie verlassen, indem Sie einen neuen, separaten Container für Ihre Arbeit erstellen und dort weiterarbeiten. Auf diese Weise können Sie experimentieren und neue Dinge ausprobieren, ohne den Produktionscode zu beeinträchtigen. Git-Benutzer wissen, dass das Branching-Modell von Git besonders und unglaublich leistungsfähig ist; es ist eine der coolsten Funktionen dieses VCS. Es ist schnell und leichtgewichtig, und das Wechseln zwischen den Branches ist genauso schnell wie das Erstellen oder Löschen. Man könnte sagen, dass Git Workflows, die viel Branching und Merging verwenden, geradezu fördert.

Git überlässt es Ihnen völlig, wie viele Branches Sie erstellen und wie oft Sie sie mergen. Wenn Sie alleine codieren, können Sie selbst entscheiden, wann Sie einen neuen Branch erstellen und wie viele Sie behalten möchten. Das ändert sich jedoch, wenn Sie in einem Team arbeiten. Git stellt das Werkzeug zur Verfügung, aber Sie und Ihr Team sind dafür verantwortlich, es optimal zu nutzen!

In diesem Artikel werde ich über Branching-Strategien und verschiedene Arten von Git-Branches sprechen. Ich werde Ihnen auch zwei gängige Branching-Workflows vorstellen: Git Flow und GitHub Flow.

Teamwork: Vereinbarung schriftlich festhalten

Bevor wir verschiedene Möglichkeiten zur Strukturierung von Releases und zur Integration von Änderungen untersuchen, sprechen wir über Konventionen. Wenn Sie in einem Team arbeiten, müssen Sie sich auf einen gemeinsamen Workflow und eine Branching-Strategie für Ihre Projekte einigen. Es ist ratsam, dies schriftlich festzuhalten, um es allen Teammitgliedern zugänglich zu machen.

Zugegeben, nicht jeder schreibt gerne Dokumentationen oder Richtlinien, aber die Festlegung von Best Practices vermeidet nicht nur Fehler und Kollisionen, sondern hilft auch beim Onboarding neuer Teammitglieder. Ein Dokument, das Ihre Branching-Strategien erklärt, hilft ihnen zu verstehen, wie Sie arbeiten und wie Ihr Team Software-Releases handhabt.

Hier sind ein paar Beispiele aus unserer eigenen Dokumentation

• master stellt den aktuellen öffentlichen Release-Branch dar
• next stellt den nächsten öffentlichen Release-Branch dar (so können wir Hotfixes auf master committen, ohne unerwünschte Änderungen zu übernehmen)
• Feature-Branches werden unter feature/ gruppiert
• WIP-Branches werden unter wip/ gruppiert (diese können zur Erstellung von "Backups" Ihrer persönlichen WIPs verwendet werden)

Ein anderes Team könnte eine andere Meinung zu diesen Dingen haben (z. B. zu "wip"- oder "feature"-Gruppen), was sich sicherlich in ihrer eigenen Dokumentation widerspiegeln wird.

Integration von Änderungen und Strukturierung von Releases

Wenn Sie darüber nachdenken, wie Sie mit Branches in Ihren Git-Repositories arbeiten, sollten Sie wahrscheinlich damit beginnen, wie Sie Änderungen integrieren und Releases strukturieren. All diese Themen sind eng miteinander verbunden. Um Ihnen zu helfen, Ihre Optionen besser zu verstehen, betrachten wir zwei verschiedene Strategien. Die Beispiele sollen die Extreme des Spektrums veranschaulichen, weshalb sie Ihnen einige Ideen geben sollten, wie Sie Ihren eigenen Branching-Workflow gestalten können.

• Mainline Development
• State, Release und Feature Branches

Die erste Option könnte als "immer integrieren" beschrieben werden, was im Grunde bedeutet: integrieren Sie Ihre eigene Arbeit immer mit der Arbeit des Teams. Bei der zweiten Strategie sammeln Sie Ihre Arbeit und veröffentlichen eine Sammlung davon, d. h. verschiedene Arten von Branches treten auf den Plan. Beide Ansätze haben ihre Vor- und Nachteile, und beide Strategien können für einige Teams funktionieren, aber nicht für andere. Die meisten Entwicklungsteams arbeiten irgendwo zwischen diesen Extremen.

Beginnen wir mit der Mainline-Entwicklung und erklären, wie diese Strategie funktioniert.

Mainline Development

Ich habe es schon gesagt, aber das Motto dieses Ansatzes ist "immer integrieren". Sie haben einen einzigen Branch, und jeder trägt bei, indem er in die Mainline committet.

Denken Sie daran, dass wir zur Vereinfachung dieses Beispiels sprechen. Ich bezweifle, dass irgendein Team in der realen Welt mit einer so einfachen Branching-Struktur arbeitet. Sie hilft jedoch, die Vorteile und Nachteile dieses Modells zu verstehen.

Erstens haben Sie nur einen Branch, was es einfach macht, die Änderungen in Ihrem Projekt zu verfolgen. Zweitens müssen die Commits relativ klein sein: Sie können es sich nicht leisten, große, aufgeblähte Commits in einer Umgebung zu machen, in der ständig in den Produktionscode integriert wird. Infolgedessen müssen die Test- und QA-Standards Ihres Teams erstklassig sein! Wenn Sie keine qualitativ hochwertige Testumgebung haben, funktioniert der Mainline-Entwicklungsansatz nicht für Sie. 

State, Release und Feature Branches

Betrachten wir nun das Gegenteil und wie man mit verschiedenen Arten von Branches arbeitet. Sie alle haben eine andere Aufgabe: Neue Features und experimenteller Code werden in eigenen Branches gehalten, Releases können in eigenen Branches geplant und verwaltet werden, und sogar verschiedene Zustände in Ihrem Entwicklungsfluss können durch Branches repräsentiert werden.

Denken Sie daran, dass dies alles von den Bedürfnissen Ihres Teams und den Anforderungen Ihres Projekts abhängt. Auch wenn dieser Ansatz auf den ersten Blick kompliziert erscheinen mag, ist es alles eine Frage der Übung und Gewöhnung.

Nun wollen wir zwei Haupt*arten* von Branches genauer untersuchen: langlaufende Branches und kurzlebige Branches.

Langlaufende Branches

Jedes Git-Repository enthält mindestens einen langlaufenden Branch, der typischerweise master oder main genannt wird. Natürlich kann Ihr Team beschlossen haben, andere langlaufende Branches in einem Projekt zu haben, zum Beispiel etwas wie develop, production oder staging. All diese Branches haben eines gemeinsam: Sie existieren während der gesamten Lebensdauer eines Projekts. 

Ein Mainline-Branch wie master oder main ist ein Beispiel für einen langlaufenden Branch. Darüber hinaus gibt es sogenannte Integrations-Branches, wie develop oder staging. Diese Branches repräsentieren normalerweise Zustände im Release- oder Deployment-Prozess eines Projekts. Wenn Ihr Code verschiedene Zustände in seinem Entwicklungslebenszyklus durchläuft – z. B. von der Entwicklung über Staging bis zur Produktion – ist es sinnvoll, diese Struktur auch in Ihren Branches widerzuspiegeln.

Eine letzte Sache zu langlaufenden Branches: Die meisten Teams haben eine Regel wie "nicht direkt in einen langlaufenden Branch committen". Stattdessen werden Commits normalerweise über einen Merge oder Rebase integriert. Es gibt zwei Hauptgründe für eine solche Konvention:

• Qualität: Kein ungetesteter oder nicht überprüfter Code sollte in eine Produktionsumgebung gelangen.
• Release-Bündelung und -Planung: Möglicherweise möchten Sie neuen Code in Batches veröffentlichen und die Releases sogar im Voraus planen.

Als Nächstes: kurzlebige Branches, die normalerweise für bestimmte Zwecke erstellt und dann gelöscht werden, nachdem der Code integriert wurde.

Kurzlebige Branches

Im Gegensatz zu langlaufenden Branches werden kurzlebige Branches für temporäre Zwecke erstellt. Sobald sie ihren Zweck erfüllt und der Code in die Mainline (oder einen anderen langlaufenden Branch) integriert wurde, werden sie gelöscht. Es gibt viele verschiedene Gründe, einen kurzlebigen Branch zu erstellen, z. B. die Arbeit an einem neuen und experimentellen Feature, die Behebung eines Fehlers, die Refaktorierung Ihres Codes usw.

Typischerweise basiert ein kurzlebiger Branch auf einem langlaufenden Branch. Nehmen wir an, Sie beginnen mit der Arbeit an einem neuen Feature Ihrer Software. Sie könnten das neue Feature auf Ihrem langlaufenden main-Branch basieren. Nach mehreren Commits und einigen Tests entscheiden Sie, dass die Arbeit abgeschlossen ist. Das neue Feature kann in den main-Branch integriert werden, und nachdem es gemerged oder gerebased wurde, kann der Feature-Branch gelöscht werden. 

Zwei beliebte Branching-Strategien

Im letzten Abschnitt dieses Artikels betrachten wir zwei beliebte Branching-Strategien: Git Flow und GitHub Flow. Auch wenn Sie und Ihr Team sich für etwas völlig anderes entscheiden können, können Sie diese als Inspiration für Ihre eigene Branching-Strategie nehmen.

Git Flow

Eine bekannte Branching-Strategie heißt Git Flow. Der main-Branch spiegelt immer den aktuellen Produktionszustand wider. Es gibt einen zweiten langlaufenden Branch, der typischerweise develop genannt wird. Alle Feature-Branches starten hier und werden in develop gemerged. Auch ist er der Ausgangspunkt für neue Releases: Entwickler öffnen einen neuen release-Branch, arbeiten daran, testen ihn und committen ihre Bugfixes auf einem solchen Release-Branch. Sobald alles funktioniert und Sie sicher sind, dass es für die Produktion bereit ist, mergen Sie es zurück in main. Als letzter Schritt fügen Sie ein Tag für den Release-Commit auf main hinzu und löschen den release-Branch.

Git Flow funktioniert ziemlich gut für verpackte Software wie (Desktop-)Anwendungen oder Bibliotheken, scheint aber für Website-Projekte ein wenig übertrieben zu sein. Hier ist der Unterschied zwischen dem Main-Branch und dem Release-Branch oft nicht groß genug, um von der Unterscheidung zu profitieren. 

Wenn Sie eine Git-Desktop-GUI wie Tower verwenden, finden Sie die möglichen Aktionen in der Benutzeroberfläche und müssen keine neuen Befehle auswendig lernen.

GitHub Flow

Wenn Sie und Ihr Team den Ansatz der kontinuierlichen Auslieferung mit kurzen Produktionszyklen und häufigen Releases verfolgen, empfehle ich Ihnen, sich GitHub Flow anzusehen. 

Er ist extrem schlank und einfach: Es gibt einen langlaufenden Branch, den Standard-main-Branch. Alles, woran Sie gerade arbeiten, hat seinen eigenen separaten Branch. Es spielt keine Rolle, ob es sich um ein Feature, einen Bugfix oder ein Refactoring handelt.

Was ist die "beste" Git-Branching-Strategie?

Wenn Sie 10 verschiedene Teams fragen, wie sie Git-Branches verwenden, erhalten Sie wahrscheinlich 10 verschiedene Antworten. Es gibt keine "beste" Branching-Strategie und keinen perfekten Workflow, den jeder übernehmen sollte. Um das beste Modell für Sie und Ihr Team zu finden, sollten Sie sich zusammensetzen, Ihr Projekt analysieren, über Ihre Release-Strategie sprechen und dann einen Branching-Workflow entscheiden, der Sie bestmöglich unterstützt.

Wenn Sie tiefer in fortgeschrittene Git-Tools eintauchen möchten, können Sie gerne mein (kostenloses!) „Advanced Git Kit“ ansehen: Es ist eine Sammlung kurzer Videos zu Themen wie Branching-Strategien, Interactive Rebase, Reflog, Submodules und vielem mehr.