Was ist Git?

Git ist ein freies und quelloffenes, verteiltes Versionskontrollsystem, das entwickelt wurde, um alles von kleinen bis hin zu großen Projekten schnell und effizient zu bearbeiten. Es wurde 2005 von Linus Torvalds gegründet, um die Entwicklung des Linux-Kernels zu unterstützen. Git erleichtert die Zusammenarbeit zwischen Entwicklern, indem es ihnen ermöglicht, Änderungen am Quellcode während der Softwareentwicklung zu verfolgen, sodass mehrere Entwickler gleichzeitig an verschiedenen Teilen eines Projekts arbeiten können.

Die Verzweigung ist eines der wichtigsten Merkmale. Git ermöglicht es Entwicklern, Branches zu erstellen, in denen sie unabhängig vom Hauptprojekt (in der Regel im „Master“-Branch) an neuen Funktionen oder Korrekturen arbeiten können. Sobald die Arbeit an einem Zweig abgeschlossen ist, kann er wieder in den Hauptzweig oder einen anderen Zweig eingefügt werden.

Git Branch Strategie

Ohne klare Standards für die Branch-Verwaltung werden Sie mit Fragen überschwemmt wie: „Was war der Zweck der Erstellung dieses Branches?“, „Von welchem Commit ist dieser Branch abgewichen?“, „Von welchem Branch soll ich abzweigen?“, „Wohin soll mein Branch zusammengeführt werden?“, „Welcher Branch ist der neueste?“, „Welcher Branch ist die eingesetzte Version?“ Solche Unwägbarkeiten können zu einem Chaos im Projekt führen.

Git-Branching sind Arbeitsabläufe zur effektiven Verwaltung der Git-Branches eines Projekts. Sie können zwar Ihre eigene Zweigstellenstrategie entwickeln, doch gibt es in der Branche bewährte Verfahren für ein effektives Zweigstellenmanagement. In diesem Beitrag werden zwei beliebte Verfahren vorgestellt: Git Flow und GitHub Flow.

Git-Flow

Git Flow ist eine Branching-Strategie, die durch einen Blogbeitrag mit dem Titel „A successful Git branching model“ von Vincent Driessen im Jahr 2010 populär wurde.

In Git Flow werden Zweige in drei Haupttypen unterteilt: Main-, Develop-, und Supporting-Branches, wobei letztere weiter in Feature-, Release- und Hotfix-Branches unterteilt sind.

Die Branches Main und Develop werden während des gesamten Entwicklungsprozesses beibehalten. Im Gegensatz dazu werden unterstützende Branches nach Bedarf erstellt und gelöscht, sobald ihre Aufgabe erfüllt ist, was einen parallelen Arbeitsablauf innerhalb des Teams ermöglicht. Schauen wir uns die einzelnen Arten an:

• Main Branch

Der Main Branch speichert die offizielle Veröffentlichungshistorie. Es wird zu Beginn des Projekts erstellt und während des gesamten Entwicklungsprozesses gepflegt. Jede eingesetzte Version wird mit Tags gekennzeichnet.

• Branches entwickeln

Dieser Branch dient als Integrations-Branch für Funktionen. Sobald die Entwicklung abgeschlossen ist, wird sie mit dem Main Branch zusammengeführt.

• Feature Branch

Ein Feature Branch wird für die Entwicklung eines einzelnen Features verwendet. Er zweigt vom Develop-Branch ab und wird nach Fertigstellung wieder mit diesem zusammengeführt. Beim Zusammenführen sollte ein Merge Commit erstellt werden, anstatt Fast-Forward zu verwenden, um sicherzustellen, dass der Verlauf nach Merkmalen gruppiert wird. Diese Branches werden im Format Feature/Branch-Name benannt.

• Release Branch

Der Release Branch dient der Vorbereitung der Softwareverteilung. Er zweigt vom Develop-Branch ab, um kleinere Änderungen oder Fehlerkorrekturen vor der Bereitstellung durchzuführen. Sobald es fertig ist, wird es in den Main- und Develop-Branch zusammengeführt, wobei die Version des Main Branch mit Tags markiert wird. Diese Trennung ermöglicht es anderen Teammitgliedern, die Entwicklung von Funktionen parallel fortzusetzen, ohne in den Bereitstellungsprozess einbezogen zu werden. Diese Branches werden wie release/v1.1 benannt.

• Hotfix Branch

Wenn ein Problem in einer bereitgestellten Version auftritt, wird ein Hotfix Branch für die Behebung verwendet. Es wird vom Main Branch abgezweigt und, sobald das Problem behoben ist, wieder mit dem Main- und Develop-Branch zusammengeführt. Dadurch kann das Team die Entwicklung der Funktionen parallel fortsetzen, ohne durch den Hotfix abgelenkt zu werden. Hotfix-Branches werden im Format hotfix/v1.0.1 benannt.

Die Grenzen von Git Flow: Nicht für Webanwendungen geeignet

Vincent Driessen hat ein Jahrzehnt nach der Veröffentlichung von „A successful Git branching model“ im Jahr 2010 eine nachdenkliche Anmerkung im Jahr 2020 zu seinem ursprünglichen Beitrag verfasst. Hier ist eine Zusammenfassung seiner Überlegungen:

„Dieses Modell wurde 2010 entwickelt, also vor mehr als 10 Jahren und nicht lange nachdem Git selbst ins Leben gerufen wurde. In diesen 10 Jahren ist Git-Flow (das in diesem Artikel vorgestellte Verzweigungsmodell) in vielen Software-Teams so populär geworden, dass man begonnen hat, es als eine Art Standard zu behandeln – aber leider auch als Dogma oder Allheilmittel.

In diesen 10 Jahren hat Git selbst die Welt im Sturm erobert, und die beliebteste Art von Software, die mit Git entwickelt wird, verschiebt sich immer mehr in Richtung Webanwendungen – zumindest in meiner Filterblase. Webanwendungen werden in der Regel kontinuierlich bereitgestellt und nicht zurückgesetzt, und Sie müssen nicht mehrere Versionen der Software unterstützen, die in freier Wildbahn laufen.

Dies ist nicht die Art von Software, die ich im Sinn hatte, als ich vor 10 Jahren den Blogbeitrag schrieb. Wenn Ihr Team Software kontinuierlich bereitstellt, würde ich vorschlagen, einen viel einfacheren Arbeitsablauf (wie GitHub Flow) zu verwenden, anstatt zu versuchen, Git-Flow in Ihr Team zu integrieren.“

Git Flow eignet sich besonders für Projekte, bei denen eine explizite Versionsverwaltung erforderlich ist, wie z. B. Smartphone-Anwendungen, Open-Source-Bibliotheken/Frameworks und dergleichen.

Bei Webanwendungen wird den Benutzern in der Regel nur die aktuellste Version angezeigt, sodass es nicht notwendig ist, mehrere parallele Versionen zu unterstützen. Außerdem können Webanwendungen mehrmals am Tag veröffentlicht werden. In Anbetracht dieser Eigenschaften ist Git Flow für die Entwicklung von Webanwendungen möglicherweise nicht die beste Wahl.

Github flow

GitHub Flow ist eine einfache, aber effektive Strategie zur Verwaltung von Branches in der Softwareentwicklung. Es wurde von GitHub entwickelt und ist speziell für Umgebungen mit kontinuierlicher Bereitstellung konzipiert, um den Entwicklungsprozess zu rationalisieren und schnelle und kontinuierliche Software-Releases zu ermöglichen.

• Main Branch: ähnlich wie bei GitFlow der Main Branch. Dieser Branch enthält die Release-Version des Codes.
• Feature Branch: Entwickler verzweigen direkt vom Main Branch, um an neuen Funktionen zu arbeiten.

Zu den wichtigsten Schritten von GitHub Flow gehören:

1. Einen Branch zu erstellen

Wenn Sie eine neue Funktion hinzufügen, erstellen Sie einen Feature Branch aus dem Main Branch. Benennen Sie den Branch kurz und klar, um die Funktion zu kennzeichnen, auf die sie abzielt, so dass andere Mitarbeiter ihren Zweck auf einen Blick erkennen können.

2. Änderungen vornehmen

Fahren Sie mit der Durchführung von Änderungen oder dem Hinzufügen neuer Features im neu erstellten Branch fort. Dieser Branch wirkt sich nicht auf andere Repositories aus, so dass Sie die Flexibilität haben, Änderungen rückgängig zu machen oder weitere Anpassungen vorzunehmen, wenn Fehler auftreten. Übertragen Sie Ihre Änderungen und veröffentlichen Sie sie. Auf diese Weise können Sie Ihre Arbeit auf einem entfernten Speicherplatz sichern und anderen Mitarbeitern die Möglichkeit geben, die Änderungen zu überprüfen und zu ergänzen.

3. Einen Pull Request erstellen

Um Feedback zu Ihren Änderungen zu erhalten, können Sie einen PR (Pull Request) erstellen. Dieser Prozess ermöglicht es Ihnen, Bewertungen Ihrer Änderungen von anderen Mitarbeitern zu erhalten. Darüber hinaus können Sie vor dem Zusammenführen in den Main Branch die Genehmigung von Überprüfungen vorschreiben.

4. Zusammenführen des Pull Request

Sobald der PR genehmigt ist, können Sie ihn mit dem Main Branch zusammenführen. Auch nach dem Zusammenführen bleibt der Commit-Verlauf erhalten, damit zukünftige Mitwirkende die Änderungen nachvollziehen können.

Der Vorteil von GitHub Flow liegt in seiner Einfachheit. Im Gegensatz zu komplexen Branch-Strategies stellt GitHub Flow sicher, dass nur Code, der für die Bereitstellung bereit ist, in den Main Branch zusammengeführt wird, so dass sich der Code im Main Branch immer in einem bereitstellungsfähigen Zustand befindet. Dieser Ansatz ist ideal für sich schnell entwickelnde Projekte und kleine Teams.