Teamarbeit ohne Verwirrung: Verzweigungsstrategien in Git verstehen

Einführung

Git ist zum De-facto-Industriestandard für die Versionskontrolle bei der Softwareerstellung geworden. Um zu erfahren, was Git ist und wie man damit anfängt, lesen Sie zunächst meinen Artikel darüber. Hast du es gelesen? Großartig, lasst uns weitermachen! Ob es Ihnen gefällt oder nicht, das Instrument, das Linus Towalds geschaffen hat, wird nicht in den Ruhestand gehen. Daher ist es sinnvoll, darüber zu sprechen, wie verteilte Teams in Git arbeiten und welche Verzweigungsstrategie man dafür wählen sollte. Und das ist keineswegs eine leere Frage. In einer Situation, in der ein neues Team aus Entwicklern zusammengestellt wird, die noch nicht miteinander zusammengearbeitet haben, ist die Verzweigungsstrategie oft eines der ersten Dinge, die entschieden werden müssen. Und es wird Leute geben, die Schaum vor dem Mund haben, um zu beweisen, dass eine Strategie besser ist als eine andere. Deshalb möchte ich Ihnen Informationen darüber vermitteln, was sie im Allgemeinen sind.

Sind Verzweigungsstrategien notwendig?

Aber sie werden gebraucht, und sie werden immer noch gebraucht. Denn wenn man sich im Team über etwas nicht einig ist, wird jeder machen, was er will:

• in der Branche arbeiten, in der er möchte;
• in andere Zweige verschmelzen, die er möchte;
• einige Zweige löschen;
• neue erstellen;
• und so weiter – jedes Teammitglied befindet sich in einem unkontrollierten Fluss.

Daher sind im Folgenden drei Strategien aufgeführt. Gehen!

GitHub Flow-Strategie

Die Verzweigungsstrategie, egal wie seltsam sie auch sein mag, wird in GitHub bevorzugt :) Daran ist eine Reihe von Regeln angehängt , die befolgt werden müssen:

1. Der Code im Master-Zweig muss intakt sein und jederzeit bereitgestellt werden können (das heißt, Sie können 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 Zweig (Feature-Zweig) basierend auf dem Hauptzweig erstellen und ihm einen aussagekräftigen Namen geben. Übertragen Sie Ihren Code lokal und übertragen Sie Ihre Änderungen regelmäßig in denselben Zweig in einem Remote-Repository.
3. Öffnen Sie einen Pull-Request ( hier können Sie nachlesen, was ein Pull-Request ist ), wenn das klare Gefühl besteht, dass die Arbeit fertig ist und in den Master-Zweig eingebunden werden kann (oder wenn Sie sich nicht sicher sind, aber Feedback dazu erhalten möchten). Die Arbeit erledigt).
4. Nachdem eine neue Funktion in einem Pull-Request genehmigt wurde, kann sie in den Master-Zweig eingebunden werden.
5. Wenn Änderungen im Hauptzweig zusammengeführt werden, müssen sie sofort auf dem Server bereitgestellt werden.

Laut GitHub Flow stellt sich heraus, dass 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 müssen. Als nächstes beginnt die Arbeit an der Umsetzung. Sie müssen Commits ständig an einen Remote-Server mit demselben Namen senden. Wenn Sie verstehen, dass alles bereit ist, müssen Sie eine Pull-Anfrage im Master-Zweig erstellen. Dann sollten sich mindestens eine oder noch besser zwei Personen diesen Code ansehen und auf „Genehmigen“ klicken. Normalerweise müssen der Teamleiter des Projekts und jemand anderes es sich ansehen, und dann können Sie die Pull-Anfrage abschließen. GitHub Flow ist auch dafür bekannt , Continuous Delivery (CD) für ein Projekt voranzutreiben . Denn wenn Änderungen am Master-Zweig vorgenommen werden, müssen diese sofort auf dem Server bereitgestellt werden.

GitFlow-Strategie

Die bisherige Strategie (GitHub Flow) war im Wesentlichen nicht sehr komplex. Es gibt zwei Arten von Zweigen: Master- und Feature-Zweig. Aber GitFlow ist ernster. Zumindest anhand des Bildes oben können Sie dies verstehen.) Wie funktioniert diese Strategie? Im Allgemeinen besteht GitFlow aus zwei permanenten Zweigen und mehreren Arten temporärer Zweige (im Kontext von GitHub Flow ist der Hauptzweig permanent und die anderen sind temporär). Ständige Niederlassungen:

• Meister: Niemand sollte diesen Ast berühren oder etwas dorthin schieben. Bei dieser Strategie zeigt der Master die neueste stabile Version an, die in der Produktion (d. h. auf dem realen Server) verwendet wird;
• Entwicklung ist der Zweig für Entwicklung. Es könnte möglicherweise instabil sein.

Die Entwicklung erfolgt über drei temporäre Hilfszweige :

1. Feature-Branches – zum Entwickeln neuer Funktionen.
2. Release-Branches – zur Vorbereitung der Veröffentlichung einer neuen Version des Projekts.
3. Hotfix-Zweige sind eine schnelle Lösung für einen Fehler, der bereits von echten Benutzern auf einem echten Server festgestellt 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 im Entwicklungszweig einen Pull-Request erstellen. Es ist klar, dass es in großen Teams gleichzeitig mehr als einen Feature-Zweig geben kann. Achten Sie noch einmal auf das Bild am Anfang der Beschreibung der GitFlow-Strategie.

Zweige freigeben

Wenn die erforderliche Anzahl neuer Funktionen im Entwicklungszweig vorbereitet wurde, können Sie die Veröffentlichung einer neuen Version des Produkts vorbereiten. Der Release-Zweig wird uns dabei helfen. die auf Basis des Entwicklungszweigs erstellt wird. Während 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 ebenfalls wieder in die Entwicklung integriert werden. Dies geschieht, um die Branche zu stabilisieren und weiterzuentwickeln. Wenn die Tester sagen, dass der Zweig stabil genug für eine neue Version ist, wird er mit dem Hauptzweig zusammengeführt. Als nächstes wird auf diesem Commit ein Tag erstellt (Tag: Mehr darüber können Sie hier lesen ), dem eine Versionsnummer zugewiesen wird. Als Beispiel können Sie sich das Bild am Anfang der Strategie ansehen. Tag 1.0 ist also nur eine Bezeichnung, die Version 1.0 des Projekts anzeigt. Und das Letzte ist ein Branch-Hotfix.

Hotfix-Zweige

Hotfix-Zweige sind auch für die Veröffentlichung einer neuen Version im Master vorgesehen. Der einzige Unterschied besteht darin, dass diese Veröffentlichung nicht geplant ist. Es gibt Situationen, in denen Mängel zur Freigabe gelangen und bereits in der Produktion entdeckt werden. Beispiel iOS: Sobald eine neue Version veröffentlicht wird, erhält man sofort eine Reihe von Updates mit Korrekturen für Fehler, die nach der Veröffentlichung entdeckt werden. In diesem Zusammenhang ist es notwendig, diesen Fehler schnell zu beheben und eine neue Version herauszubringen. Auf unserem Bild entspricht dies der Version 1.0.1. Die Idee ist, dass die Arbeit an neuen Funktionen möglicherweise nicht dann aufhört, wenn Sie einen Fehler auf einem echten Server beheben müssen (wie wir „in Produktion“ sagen: wiederum eine Kopie des englischen Wortes „Produktion“). Der Hotfix-Zweig sollte aus dem Master-Zweig erstellt werden, da er den Status darstellt, der in der Produktion funktioniert. Sobald die Lösung für den Fehler fertig ist, wird sie in den Master eingefügt und ein neues Etikett erstellt. Genau wie bei der Vorbereitung eines Release-Zweigs sollte ein Hotfix-Zweig seine Lösung in den Entwicklungszweig einbinden.

Die Forking-Workflow-Strategie

Im Rahmen der Forking-Workflow-Strategie erfolgt die Entwicklung so, dass es zwei Repositories gibt:

1. Das ursprüngliche Repository, in dem alle Änderungen zusammengeführt werden.
2. Ein Fork-Repository (das ist eine Kopie des Original-Repositorys im Besitz eines anderen Entwicklers, der Änderungen am Original vornehmen möchte).

Klingt bisher etwas seltsam, oder? Für diejenigen, die bereits mit der Open-Source-Entwicklung in Berührung gekommen sind, ist dieser Ansatz bereits bekannt. Diese Strategie bietet folgenden Vorteil: Die Entwicklung kann in einem Fork-Repository durchgeführt werden, ohne dass Rechte für die gemeinsame Entwicklung im Original-Repository gewährt werden. Selbstverständlich hat der Eigentümer des ursprünglichen Repositorys das Recht, die vorgeschlagenen Änderungen abzulehnen. Oder stimmen Sie zu und töten Sie sie. Dies ist sowohl für den Eigentümer des Original-Repositorys als auch für den Entwickler praktisch, der an der Erstellung eines Produkts teilnehmen möchte. Sie können beispielsweise Änderungen am Linux-Kernel vorschlagen . Wenn Linus entscheidet, dass sie Sinn machen, werden die Änderungen hinzugefügt (!!!).

Das Beispiel für einen Forking-Workflow

Der Forking Flow wird auf GitHub verwendet, wenn Sie eine Bibliothek verwenden möchten. Es weist einen Defekt auf, der eine vollständige Nutzung verhindert. Nehmen wir an, Sie haben sich ausreichend mit dem Problem befasst und kennen die Lösung. Mithilfe der Forking-Workflow-Strategie können Sie dieses Problem lösen, ohne Rechte für die Arbeit im ursprünglichen Bibliotheks-Repository zu erteilen. Um zu beginnen, müssen Sie ein Repository auswählen, zum Beispiel den Spring Framework-Kern . Suchen Sie die Fork-Schaltfläche in der oberen rechten Ecke und klicken Sie darauf: Dies wird einige Zeit dauern, danach wird eine Kopie dieses ursprünglichen Repositorys in Ihrem angezeigt persönliches Konto, das anzeigt, dass es sich um einen Fork handelt: Dann können Sie wie gewohnt mit diesem Repository arbeiten, Änderungen am Master-Zweig hinzufügen und, wenn alles fertig ist, einen Pull-Request an das ursprüngliche Repository erstellen. Klicken Sie dazu auf die Schaltfläche „Neue Pull-Anfrage“ :

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 größer die Auswahl, desto schwieriger wird es, sich jetzt für eine Strategie zu entscheiden. Offensichtlich gibt es keine allgemeingültige Antwort. Es hängt alles von der Situation ab. Es gibt jedoch ein paar Empfehlungen, die dabei helfen können:

1. Es ist besser, zuerst die einfachste Strategie zu wählen. Gehen Sie nur bei Bedarf zu komplexeren Strategien über.
2. Ziehen Sie Strategien in Betracht, die möglichst wenige Arten von Entwicklerzweigen haben.
3. Schauen Sie sich die Vor- und Nachteile verschiedener Strategien an und wählen Sie je nach Projekt die richtige aus.

Das ist alles, was ich Ihnen über die Verzweigungsstrategie in Git sagen wollte. Vielen Dank für Ihre Aufmerksamkeit :) Abonnieren Sie mein GitHub-Konto . Ich poste dort häufig meine Arbeit in verschiedenen Technologien und Tools, die ich in meiner Arbeit verwende

Nützliche Links

• GitHub-Flow: Der beste Weg, Git und GitHub zu nutzen
• Pull-Anfragen auf GitHub oder Wie kann ich Änderungen am Projekt einer anderen Person vornehmen?
• GitHub: Über Pull-Requests
• Kontinuierliche Integration, Bereitstellung und Bereitstellung differenziert
• Git-Grundlagen: Arbeiten mit Tags
• Habr: Erfolgreiches Verzweigungsmodell für Git