Teamarbeit ohne Verwirrung: Verzweigungsstrategien in Git verstehen

Einführung

Git ist zum De-facto-Industriestandard für Versionskontrollsysteme in der Softwareentwicklung geworden. Sie sollten zuerst meinen Artikel darüber lesen, was Git ist und wie man damit anfängt. Hast du es gelesen? Ausgezeichnet, los geht's! Ob es Ihnen gefällt oder nicht, dieses von Linus Tovalds entwickelte Tool wird nicht in den Ruhestand gehen. Daher ist es sinnvoll, darüber zu sprechen, wie verteilte Teams mit Git arbeiten und welche Verzweigungsstrategie sie dafür wählen sollten. Das ist keine belanglose Frage. Bei der Zusammenstellung eines neuen Entwicklungsteams, das zuvor noch nicht zusammengearbeitet hat, ist die Verzweigungsstrategie oft eines der ersten Dinge, die entschieden werden müssen. Und manche Leute werden Schaum vor dem Mund haben, um zu beweisen, dass eine Strategie besser ist als eine andere. Deshalb möchte ich Ihnen einige allgemeine Informationen über sie übermitteln.

Sind Verzweigungsstrategien notwendig?

Sie sind tatsächlich notwendig. Sehr nötig. Denn wenn sich das Team über etwas nicht einig ist, dann macht jedes Teammitglied, was es will:

• in welcher Branche auch immer arbeiten
• in beliebige andere Zweige übergehen
• Löschen einiger Zweige
• neue schaffen
• Daher agiert jedes Teammitglied in einem unkontrollierten Ablauf.

Aus diesem Grund möchten wir im Folgenden drei Strategien berücksichtigen. Lass uns gehen!

GitHub-Flow

Seltsamerweise wird diese Verzweigungsstrategie auf GitHub bevorzugt :) Sie enthält eine Reihe von Regeln :

1. Der Code im Hauptzweig darf nicht beschädigt werden. Es sollte jederzeit einsatzbereit sein. Das heißt, Sie dürfen dort keinen Code einfügen, der Sie daran hindert, das Projekt zu erstellen und auf dem Server bereitzustellen.
2. Wenn Sie planen, an neuen Funktionen zu arbeiten, müssen Sie einen neuen Feature-Branch basierend auf dem Master-Branch erstellen und ihm einen aussagekräftigen Namen geben. Übertragen Sie Ihren Code lokal und übertragen Sie Ihre Änderungen regelmäßig an denselben Zweig im Remote-Repository.
3. Öffnen Sie einen Pull-Request (über Pull-Requests können Sie hier lesen), wenn Sie der Meinung sind, dass die Arbeit fertig ist und in den Master-Zweig eingebunden werden kann (oder wenn Sie sich nicht sicher sind, aber Feedback zur geleisteten Arbeit erhalten möchten).
4. Nachdem die neue Funktion im Pull-Request genehmigt wurde, kann sie in den Master-Zweig eingebunden werden.
5. Wenn die Änderungen im Hauptzweig zusammengeführt werden, sollten sie sofort auf dem Server bereitgestellt werden.

Laut GitHub Flow müssen Sie, bevor Sie mit der Arbeit an etwas Neuem beginnen, sei es ein Fix oder ein neues Feature, einen neuen Branch basierend auf Master erstellen und ihm einen passenden Namen geben. Als nächstes beginnt die Arbeit an der Umsetzung. Sie sollten ständig Commits an den Remote-Server mit demselben Namen senden. Wenn Sie zu dem Schluss kommen, dass alles bereit ist, müssen Sie eine Pull-Anfrage an den Master-Zweig erstellen. Dann sollten sich mindestens eine oder noch besser zwei Personen diesen Code ansehen, bevor sie auf „Genehmigen“ klicken. Normalerweise sollten der Teamleiter des Projekts und eine zweite Person unbedingt einen Blick darauf werfen. Anschließend können Sie die Pull-Anfrage abschließen. GitHub Flow ist auch dafür bekannt , Continuous Delivery (CD) in Projekten voranzutreiben . Dies liegt daran, dass Änderungen, die in den Hauptzweig gelangen, sofort auf dem Server bereitgestellt werden sollten.

GitFlow

Die bisherige Strategie (GitHub Flow) ist im Kern nicht sehr kompliziert. Es gibt zwei Arten von Zweigen: Master- und Feature-Zweig. Aber GitFlow ist ernster. Zumindest das Bild oben sollte das deutlich machen :) Wie funktioniert diese Strategie? Im Allgemeinen besteht GitFlow aus zwei persistenten Zweigen und mehreren Arten temporärer Zweige. Im Kontext von GitHub Flow ist der Hauptzweig dauerhaft und die anderen sind temporär. Permanente Zweige

• Meister: Niemand sollte diesen Ast berühren oder etwas dorthin schieben. Bei dieser Strategie stellt Master die neueste stabile Version dar, die in der Produktion (also auf einem echten Server) verwendet wird.
• development: Der Entwicklungszweig. Es könnte instabil sein.

Die Entwicklung erfolgt mithilfe von drei temporären Hilfszweigen :

1. Feature-Branches – zum Entwickeln neuer Funktionen.
2. Release-Zweige – zur Vorbereitung der Veröffentlichung einer neuen Version des Projekts.
3. Hotfix-Zweige – zum schnellen Beheben eines Fehlers, der von echten Benutzern auf einem echten Server gefunden wurde.

Feature-Zweige

Feature-Branches werden von Entwicklern für neue Funktionen erstellt. Sie sollten immer auf Basis des Entwicklungszweigs erstellt werden. Nachdem Sie die Arbeit an der neuen Funktionalität abgeschlossen haben, müssen Sie eine Pull-Anfrage an den Entwicklungszweig erstellen. Offensichtlich können große Teams gleichzeitig über mehr als einen Feature-Zweig verfügen. Schauen Sie sich noch einmal das Bild am Anfang der Beschreibung der GitFlow-Strategie an.

Zweige freigeben

Wenn der erforderliche Satz neuer Funktionen im Entwicklungszweig bereitsteht, können Sie sich auf die Veröffentlichung einer neuen Version des Produkts vorbereiten. Dabei hilft uns ein Release-Branch, der auf Basis des Development-Branchs erstellt wird. Wenn Sie mit dem Release-Zweig arbeiten, müssen Sie alle Fehler finden und beheben. Alle neuen Änderungen, die zur Stabilisierung des Release-Zweigs erforderlich sind, müssen auch wieder in den Entwicklungszweig zusammengeführt werden. Dies geschieht, um auch den Entwicklungszweig zu stabilisieren. Wenn Tester sagen, dass der Zweig stabil genug für eine neue Version ist, wird er mit dem Hauptzweig zusammengeführt. Später wird für diesen Commit ein Tag erstellt, dem eine Versionsnummer zugewiesen wird. Um ein Beispiel zu sehen, schauen Sie sich das Bild am Anfang der Strategie an. Dort sehen Sie Tag 1.0– Dies ist nur ein Tag, der auf Version 1.0 des Projekts hinweist. Und schließlich haben wir den Hotfix-Zweig.

Hotfix-Zweige

Hotfix-Zweige sind auch für die Veröffentlichung einer neuen Version im Master-Zweig gedacht. Der einzige Unterschied besteht darin, dass diese Veröffentlichungen nicht geplant sind. Es gibt Situationen, in denen Fehler in die veröffentlichte Version gelangen und in der Produktionsumgebung entdeckt werden. Nehmen Sie iOS: Sobald eine neue Version veröffentlicht wird, erhalten Sie sofort eine Reihe von Updates mit Korrekturen für Fehler, die nach der Veröffentlichung gefunden wurden. Dementsprechend müssen wir schnell einen Fehler beheben und eine neue Version veröffentlichen. In unserem Bild entspricht dies der Version 1.0.1. Die Idee dahinter ist, dass die Arbeit an neuen Funktionen nicht dann aufhören muss, wenn ein Fehler auf einem echten Server behoben werden muss (oder, wie wir sagen, „im Produkt“ oder „in der Produktion“). Der Hotfix-Zweig sollte aus dem Master-Zweig erstellt werden, da er darstellt, was derzeit in der Produktion ausgeführt wird. Sobald der Bugfix fertig ist, Es wird mit dem Master zusammengeführt und ein neues Tag wird erstellt. Genau wie beim Vorbereiten eines Release-Zweigs sollte auch ein Hotfix-Zweig seinen Fix wieder in den Entwicklungszweig einbinden.

Forking-Workflow

Im Forking-Workflow umfasst die Entwicklung zwei Repositorys:

1. Das ursprüngliche Repository, in dem alle Änderungen zusammengeführt werden.
2. Ein Fork-Repository. Dies ist eine Kopie des Original-Repositorys, die einem anderen Entwickler gehört, der Änderungen am Original vornehmen möchte.

Klingt bisher etwas seltsam, oder? Jeder, der bereits mit der Open-Source-Entwicklung in Berührung gekommen ist, kennt diesen Ansatz bereits. Diese Strategie bietet den folgenden Vorteil: Die Entwicklung kann in einem Fork-Repository erfolgen, ohne dass Berechtigungen für die gemeinsame Entwicklung im ursprünglichen Zweig erteilt werden müssen. Selbstverständlich hat der Eigentümer des ursprünglichen Repositorys das Recht, die vorgeschlagenen Änderungen abzulehnen. Oder sie zu akzeptieren und zusammenzuführen. Dies ist sowohl für den Eigentümer des ursprünglichen Repositorys als auch für den Entwickler, der bei der Erstellung des Produkts helfen möchte, praktisch. Sie können beispielsweise Änderungen am Linux-Kernel vorschlagen . Wenn Linus entscheidet, dass sie Sinn machen, werden die Änderungen hinzugefügt (!!!).

Ein Beispiel für den Forking-Workflow

Der Forking-Workflow wird auf GitHub angewendet, wenn es eine Bibliothek gibt, die Sie verwenden möchten. Es gibt einen Fehler, der Sie daran hindert, es vollständig zu nutzen. Angenommen, Sie tauchen tief genug in das Problem ein und kennen die Lösung. Mit dem Forking-Workflow können Sie das Problem beheben, ohne Rechte zum Arbeiten im Original-Repository der Bibliothek zu haben. Um zu beginnen, müssen Sie ein Repository auswählen, beispielsweise das Spring Framework . Suchen Sie die Schaltfläche „Fork“ in der oberen rechten Ecke und klicken Sie darauf: Dies wird einige Zeit dauern. Dann erscheint in Ihrem persönlichen Konto eine Kopie des Original-Repositorys, die darauf hinweist, dass es sich um einen Fork handelt:Jetzt können Sie wie gewohnt mit diesem Repository arbeiten, Änderungen am Master-Zweig hinzufügen und wenn alles fertig ist, können Sie eine Pull-Anfrage an das ursprüngliche Repository erstellen. Klicken Sie dazu auf die Schaltfläche Neuer Pull-Request :

Welche Strategie soll man wählen?

Git ist ein flexibles und leistungsstarkes Tool, mit dem Sie mit einer Vielzahl von Prozessen und Strategien arbeiten können. Doch je mehr Möglichkeiten man hat, desto schwieriger wird es, sich für eine Strategie zu entscheiden. Es ist klar, dass es keine einheitliche Antwort für alle gibt. Alles hängt von der Situation ab. Allerdings gibt es mehrere Richtlinien, die dabei helfen können:

1. Wählen Sie am besten zunächst die einfachste Strategie. Wechseln Sie nur bei Bedarf zu komplexeren Strategien.
2. Erwägen Sie Strategien, die den Entwicklern möglichst wenige Verzweigungstypen bieten.
3. Schauen Sie sich die Vor- und Nachteile der verschiedenen Strategien an und wählen Sie dann diejenige aus, die Sie für Ihr Projekt benötigen.

Das ist alles, was ich über Verzweigungsstrategien in Git sagen wollte. Vielen Dank für Ihre Aufmerksamkeit :) Folgen Sie mir auf GitHub , wo ich oft meine Kreationen poste, die verschiedene Technologien und Tools beinhalten, die ich bei meiner Arbeit verwende.