Dieses Dokument wurde geschrieben, um die unternehmensinternen GitFlow-Regeln zu vereinheitlichen. Diese Methode ist keine Einführung von reinem GitFlow, sondern eine Mischung aus GitFlow und GitLab Flow, die sich über viele Jahre hinweg bewährt hat. Sie hilft dabei, eine saubere und lesbare Historie des Repositorys zu erhalten und eine bessere Kontrolle über Änderungen und Projekt Lebenszyklen.

Repository initialisieren

Nachdem Sie das Repository initialisiert haben, erstellen Sie eine entwickeln. und Meister Zweig, wenn er nicht standardmäßig enthalten war. Der Entwicklungszweig sollte eine Entwicklung enthalten Code die eine Spiegelung des Master-Zweigs mit neuen Funktionen ist. Der Masterzweig enthält eine stabile Version des Codes, die den Produktionsstatus darstellt. Beide haben eine unendliche Lebensdauer und werden im Vergleich zu anderen Zweigen in Git Flow nie entfernt. Richten Sie geeignete Schutzregeln ein: verlangen, dass Pull-Anfragen vor dem Zusammenführen geprüft werden und Statusprüfungen vor dem Zusammenführen verlangen. Sie können auch erwägen, nur ausgewählte Team Mitglieder, um Änderungen in den Master einzubringen.

$ git init
$ git commit --allow-empty -m "Erste Übergabe"
$ git checkout -b develop master

HINWEIS: Manchmal ist es für das Projekt wichtig, weitere unendliche Zweige hinzuzufügen, um zum Beispiel verfügbare Umgebungen zu repräsentieren. Halten Sie jedoch nach Möglichkeit die "Zweierregel" ein.

Besondere Zweige

Wenn Sie mit einer bestimmten Funktion arbeiten, stellen Sie zunächst sicher, dass Sie Ihre entwickeln. Zweig synchronisiert.

 $ git checkout develop && git pull --rebase

Checken Sie dann in Ihren Feature-Zweig aus. Benennen Sie es entsprechend dem angegebenen Schema: feature-JIRA-TASK-ID oder Sie können auch gegen diese Regel verstoßen und ihn anders benennen. Stellen Sie in diesem Fall sicher, dass er nicht mit Mustern kollidiert, die für Release, Hotfix, Bugfix, Entwicklung oder den Master-Zweig reserviert sind. Wenn Sie die JIRA-Aufgaben-IDs beibehalten, können Sie Ihre Feature-Zweige effektiver verwalten.

$ git checkout -b feature-JIRA-TASK-ID develop

Dieser Zweig sollte so lange existieren, wie die betreffende Funktion entwickelt und dann mit dem übergeordneten Zweig zusammengeführt wird. Um in Ihren lokalen Zweig zu übertragen, folgen Sie bitte diesem Befehl:

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Aufgabenbeschreibung"

Es wird empfohlen, dass Sie Ihrem lokalen Zweig weitere Commits hinzufügen und dabei die Regel "Commit early and often" befolgen. Am Ende müssen sie jedoch in einem einzigen Commit zusammengefasst werden, der eine JIRA-Aufgabe darstellt. Häufiges Commit hilft Ihnen, Ihre Entwicklungshistorie zu verwalten. Wenn das Feature fertig ist, ist es an der Zeit, einen Pull Request zu öffnen, um einen Zweig zu entwickeln. Zuerst können Sie Ihren lokalen Zweig pushen, wenn er noch nicht zu weit fortgeschritten ist:

 $ git push origin feature-JIRA-TASK-ID

Wenn der Zweig fertig ist, öffnen Sie Ihr Pull-Anfrage auf GitHub, indem Sie diesem Artikel folgen: https://help.github.com/en/articles/creating-a-pull-request

Bevor Sie einen Pull Request öffnen, stellen Sie bitte Folgendes sicher:

• a korrekte Beschreibung gegeben wurde - normalerweise würden Sie Verknüpfen Sie Ihre JIRA-Aufgabeaber Sie können auch einige nützliche Informationen zum aktuellen Code hinzufügen
• CircleCI Schritte wurden erfolgreich absolviert
• Ihr Teammitglieder wurden zugewiesen - es ist eine gute Praxis, alle Teammitglieder als Beauftragte einzubeziehen
• die Gutachter wurden ausgewählt - die Anzahl der Prüfer hängt von Ihrem Team ab
• Ihr Code ist tatsächlich reif für die Überprüfung - werfen Sie einen letzten Blick auf Ihren Code, überlegen Sie noch einmal, ob es noch etwas zu überarbeiten gibt, und testen Sie ihn lokal und stellen Sie sicher, dass sie für die weiteren Schritte bereit ist.
• Es gibt keine Merge-Konflikte und ein Zweig ist mit develop auf dem neuesten Stand - wenn es welche gibt, lösen Sie sie zuerst

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use -i flag for squash
$ git push -f origin feature-JIRA-TASK-ID # Seien Sie vorsichtig, denn das Flag -f überschreibt das entfernte Repository

• nur wichtige Übertragungen behalten - jede Übergabe sollte z.B. durch eine JIRA-Aufgabe dargestellt werden, JIRA-TASK-ID: Konfiguration einer neuen Funktion; andere sollten sein beim Umbasieren gequetscht Ihren Zweig mit dem Entwicklungszweig
• Sie haben die richtiger Zielzweig ausgewählt
• vergisst man nicht den Status Ihrer JIRA-Aufgabe ändern

Zusammenführung von Funktionszweigen

Es ist an der Zeit, Ihre Änderungen im Entwicklungszweig zusammenzuführen:

• der Pull-Antrag wurde von ausgewählten Teammitgliedern genehmigt
• alle Tests erfolgreich abgeschlossen
• es gibt keine Zusammenführungskonflikte, und der Verlauf der Übertragungen sieht gut aus

Dies kann entweder durch den Projektleiter oder den Feature-Entwickler geschehen. Führen Sie die folgenden Schritte aus, um die Zusammenführung durchzuführen:

 $ git checkout develop
 $ git merge Merkmal-JIRA-TASK-ID
 $ git push origin develop
 $ git branch -d Merkmal-JIRA-TASK-ID
 $ git push origin :Merkmal-JIRA-TASK-ID

Jetzt kann der JIRA-Aufgabenstatus geändert werden.

Veröffentlichungen

Versionszweige sollten von einer Person erstellt werden, die für die aktuelle Version verantwortlich ist. Normalerweise werden Releases in regelmäßigen Abständen erstellt, zum Beispiel nach dem Sprint Lebenszyklus.

Semantische Versionierung

Einem Versionszweig einen richtigen Namen und ein entsprechendes Tag zu geben, ist am Anfang keine leichte Aufgabe. Es ist eine gute Praxis, mit der semantischen Versionierung (https://semver.org/), was eine bessere Kontrolle ermöglicht und das Lesen der Git-Historie erleichtert. Der Versionsstring wird nach dem Schema MAJOR.MINOR.PATCH aufgebaut:

• MAJOR - Änderung, die inkompatible API-Änderungen darstellt
• MINOR - Hinzufügen neuer Funktionen in abwärtskompatibler Weise
• PATCH - Hinzufügen von rückwärtskompatiblen Fehlerkorrekturen

Sie können auch spezielle Suffixe verwenden, z.B. für Beta- oder Legacy-Zweige, oder Vorabversionen erstellen. Benennen Sie sie in diesem Fall richtig, z. B. 1.1.0-beta.4, 1.1.0-beta.5 oder 1.1.0-alpha.

Eine Freigabe machen

Der Release-Zweig sollte ein Kind von develop sein und nur Commits enthalten, die mit Bugfixes verbunden sind.

Der Name der Verzweigung sollte auf der Release-Version basieren, mit dem Präfix release-: release-MAJOR.MINOR.PATCH. Der Release-Zweig sollte sein sowohl automatisch als auch manuell vollständig getestet über die Staging-Umgebung. Wenn Fehler auftreten, ist dies die letzte Gelegenheit, die richtigen Korrekturen zu pushen und den gesamten Prozess neu zu starten, solange er nicht positiv geprüft und für die weitere Verarbeitung bereit ist. Dann sollte der Release-Commit gepusht werden, mit Änderungen des aktuellen Versionsstrings in Dateien, wie package.json. Sie sollte auch Auswirkungen auf die Datei CHANGELOG.md haben. Dies hilft Ihnen, alle Änderungen vor der eigentlichen Veröffentlichung zu verfolgen und den Inhalt für die Veröffentlichung auf GitHub vorzubereiten, wenn der Merge-Prozess abgeschlossen ist. Die Aktualisierung in einer einzigen Datei sollte alle Versionsänderungen enthalten, die in drei Kategorien gruppiert sind: Funktionen, Fehlerbehebungen und Wartung.

Im ersten Schritt sollten Sie jedoch sicherstellen, dass sowohl Ihr Entwicklungs- als auch Ihr Master-Zweig aktuell sind.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git merge master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Produkt Name M.M.P release"
 $ git push origin release-M.M.P

An diesem Punkt kann man sich entscheiden, eine weitere Pull-Anfrage an den Master mit dem Release-Zweig zu erstellen. Es kann eine gute Idee sein, eine zusätzliche Prüfung durchzuführen, wenn alle Tests auf dem entfernten Rechner gut verlaufen.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # Zusatzmeldung kann mit dem Flag -m gesetzt werden
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Gehen Sie dann zur Seite GitHub releases und klicken Sie auf die Schaltfläche "Draft new release". Wählen Sie im angezeigten Formular das Tag "Aktuelle Version" aus, legen Sie einen Titel für die Veröffentlichung fest, der dem des Release-Commits entspricht (Product Name M.M.P release), und geben Sie eine angemessene Beschreibung an, die auf der Datei CHANGELOG.md basiert. Bei öffentlichen Projekten sollte die Beschreibung eine Liste aller PR enthalten, die in der aktuellen Version enthalten sind.

Falls einige Fehlerbehebungen im Release-Zweig vorgenommen wurden, stellen Sie sicher, dass Sie Ihren Entwicklungszweig aktualisiert haben:

$ git checkout develop && git merge master
$ git push origin develo

Hotfixes und Fehlerbehebungen

Der Hauptunterschied zwischen einem Fehler und Hotfixes ist ihr Zielzweig.

Fehlerbehebung

Fehlerkorrekturen sollten als einzige Form der Codeaktualisierung vor dem Zusammenführen mit dem Master-Zweig in den Release-Zweig gepatcht werden. Erstellen Sie zunächst den Zweig aus dem aktuellen Feature-Zweig. Stellen Sie sicher, dass Sie ihn lokal auf dem neuesten Stand haben.

 $ git checkout release-M.M.P && git pull --rebase
 $ git checkout -b bugfix-M.M.P

Übertragen Sie dann die notwendigen Änderungen. Nachdem der Prozess abgeschlossen ist, erstellen Sie einen Pull-Request und leiten ihn an den Release-Zweig weiter. Folgen Sie der Anleitung aus dem Abschnitt Feature Branch. Ihr endgültiger Commit-Titel sollte dem vorgegebenen Schema entsprechen: "Bugfix M.M.P: Problem Essenz beheben". Wenn der Pull Request genehmigt ist, ist es an der Zeit, ihn in die aktuelle Version einzubinden.

 $ git checkout release-M.M.P
 $ git merge bugfix-M.M.P
 $ git push origin release-M.M.P

Hotfix

Um einen Hotfix für den Master-Zweig durchzuführen, müssen ähnliche Schritte wie bei einem Bugfix durchgeführt werden, wobei zu beachten ist, dass der Zielzweig nun der Master-Zweig ist.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P steht für die aktuelle Version

Folgen Sie dann den üblichen Entwicklungsschritten und erstellen Sie nach Abschluss des Prozesses eine Pull-Anforderung mit dem Master-Zweig als Ziel. Denken Sie daran, dass der letzte Commit dem vorgegebenen Schema "Hotfix X.Y.(Z + 1) entsprechen sollte: Problem Essenz beheben". Wenn jeder Checkpoint erfolgreich durchlaufen wurde, führen Sie einen Merge nach Master durch. Diese Schritte unterscheiden sich von denen für einen Bugfix, da wir die aktuelle Release-Version erhöhen müssen.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # Zusatzmeldung kann über das Flag -m gesetzt werden
 $ git push Ursprung X.Y.(Z+1)
 $ git push origin master
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origin :hotfix-X.Y.(Z+1)
 $ git checkout develop && git merge master
 $ git push origin develop

Spickzettel

Init-Repository

 $ git init
 $ git commit --allow-empty -m "Erste Übergabe"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Eigenschaften

$ git checkout develop && git pull --rebase
$ git checkout -b feature-JIRA-TASK-ID develop

Starten Sie Ihre Entwicklung und Übertragungen

$ git add .
$ git commit -m "IRA-TASK-ID: Aufgabenbeschreibung" #initial commit
$ git push origin Merkmal-JIRA-TASK-ID

Pull-Request öffnen

Rebase und Vorbereitung für Pull Request

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # Verwenden Sie das Flag -i für Squash
$ git push -f origin feature-JIRA-TASK-ID # Verwenden Sie dies mit Vorsicht, da das Flag -f das entfernte Repository überschreibt

Änderungen zusammenführen und Zweig löschen

$ git checkout develop #-Zweig sollte zu diesem Zeitpunkt mit dem Entwicklungszweig synchronisiert werden
$ git merge Merkmal-JIRA-TASK-ID
$ git push origin develop
$ git branch -d Merkmal-JIRA-TASK-ID
$ git push origin :Merkmal-JIRA-TASK-ID

Veröffentlichungen

$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P

Release Commit erstellen

$ git add .
$ git commit -m "Produktname M.M.P release" #initial commit
$ git push origin release-M.M.P

Pull-Request öffnen

Änderungen zusammenführen, freigeben und Zweig löschen

$ git checkout master #-Zweig sollte in diesem Stadium mit dem Master-Zweig synchronisiert werden
$ git merge release-M.M.P
$ git tag -a M.M.P # Zusatzmeldung kann über die Option -m gesetzt werden
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Fehlerbehebung

$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P

$ Fehlerbehebungen committen
$ git add .
$ git commit -m "Bugfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Pull-Request öffnen

Änderungen zusammenführen und Zweig löschen

$ git checkout release-M.M.P #-Zweig sollte in diesem Stadium mit dem aktuellen Release-Zweig synchronisiert werden
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d Fehlerbehebung-M.M.P
$ git push origin :bugfix-M.M.P

Hotfix

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P steht für die aktuelle Version

$ Übertragen von Korrekturen
$ git add .
$ git commit -m "Hotfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Pull-Request öffnen

Zusammenführen von Änderungen, Freigeben und Löschen von Zweigen

$ git checkout master # Zweig sollte zu diesem Zeitpunkt mit dem aktuellen Master synchronisiert werden
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # Zusatzmeldung kann über das Flag -m gesetzt werden
$ git push Ursprung X.Y.(Z+1)
$ git push ursprung master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin develop

Lesen Sie mehr:

• Codest's gute Praxis für die Erstellung von Software: CircleCI
• Wie erstellt man Google Chrome-Erweiterungen mit dem Styler für Netflix-Untertitel?
• React: der beliebteste JavaScript-Rahmen