Wie sollten Sie nach git-flow mit einem Hotfix einer früheren Version umgehen?

101

Wenn Sie versuchen, dem hier und mit Tools hier dokumentierten Git-Flow-Verzweigungsmodell zu folgen , wie sollten Sie mit dieser Situation umgehen:

Sie haben eine Version 1.0 und eine Version 2.0 erstellt. Dann müssen Sie einen Hotfix für 1.0 erstellen. Sie erstellen einen Hotfix-Zweig aus dem 1.0-Tag und implementieren den Fix dort. Aber was dann?

Normalerweise würden Sie zusammenführen, um ein 1.1-Release-Tag zu erstellen. Sie können 1.1 jedoch nicht bis zu einem Punkt nach 2.0 auf dem Master zusammenführen.

Ich denke, Sie könnten das Release-Tag in den Hotfix-Zweig einfügen, aber das würde einen permanenten Zweig neben dem Master erstellen, der ein Release-Tag enthalten würde. Ist das der richtige Weg?

— Klas Mellbourn
quelle

Mögliches Duplikat von Git-Flow und Master mit mehreren parallelen Release-Zweigen [obwohl die andere Frage neuer ist, hat sie nützlichere Antworten, so dass ich diese Frage als Duplikat gekennzeichnet habe]

— Danio

74

Es scheint, dass es ein Konzept für einen "Support" -Zweig im Git-Flow gibt. Dies wird verwendet, um einer früheren Version einen Hotfix hinzuzufügen.

Dieser Thread enthält weitere Informationen mit den folgenden Beispielen:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

... machen Sie Ihre Lösung, dann:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

oder mit git flowBefehlen

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

... dann Änderungen vornehmen:

git flow hotfix finish 6.0.1

— Klas Mellbourn
quelle

Behalten Sie diese Support-Zweige oder löschen Sie sie nach einiger Zeit

— Evan Hu

@EvanHu gut, behalten Sie sie sicher, solange Sie diesen Zweig irgendwo in der Produktion haben. Danach ist es eine Frage der historischen Aufzeichnung. Vielleicht möchten Sie wissen, wie Hotfixes behoben wurden, falls sie jemals wieder auftreten sollten.

— Klas Mellbourn

Man sollte eine Veröffentlichung auf dem Hotfix machen, oder? Wie können wir das machen?

— Ravindranath Akila

33

Interessante Frage! Der von Ihnen verknüpfte Ablauf setzt voraus, dass der Master die Produktion verfolgen kann. Das funktioniert nur, wenn die Produktionsversionen streng steigen. Dies gilt normalerweise für eine Website mit nur einer Produktionsversion.

Wenn Sie mehrere Produktionsversionen verwalten müssen, reicht ein Zweig zur Verfolgung der Produktion nicht aus. Eine Lösung besteht nicht darin, Master zur Verfolgung der Produktion zu verwenden. Verwenden Sie stattdessen Branchen wie release1, release2usw.

Bei diesem Ansatz benötigen Sie möglicherweise nicht einmal einen Hotfix-Zweig. Sie können das Problem in der release1Verzweigung beheben . Wenn das Update gut genug ist, erstellen Sie ein release1.1Tag im release1Zweig.

— Andomar
quelle

Sie können git-flow ändern, um die Release-Tags in den Release-Zweigen festzulegen. Das ist eine ziemlich große Veränderung. Es würde die aktuellen Skripte brechen. Auch was würde Master dann enthalten?

— Klas Mellbourn

3

Das git-flowWerkzeug ist nicht geeignet, wenn Sie mehrere Produktionsversionen unterstützen müssen. In dem in dieser Antwort vorgeschlagenen Workflow wird der Master überhaupt nicht verwendet. Sie könnten den Entwicklungszweig-Master benennen, es ist schließlich nur ein Name.

— Andomar

GitFlow unterstützt das Tracking von mehr als einer Produktionsversion

— Andre L

7

git-flow geht davon aus, dass Sie jeweils nur eine Release-Linie unterstützen, die vom Master bequem verfolgt wird. Wenn Sie mehr als 1 verwalten, müssen Sie den Git-Flow-Prozess so ändern, dass mehrere Tracker Ihrer separaten Releases vorhanden sind, die Sie unterstützen (Master-1, Master-2). Sie können weiterhin Master verwenden, um die neueste Release-Zeile zu verfolgen, zusätzlich zu oder anstelle eines bestimmten Trackers für die neueste Release-Zeile (Master anstelle von Master-2).

Leider müssen alle Git-Flow-Tools, die Sie möglicherweise verwenden, wahrscheinlich geändert werden, aber hoffentlich sind Sie mit dem Git-Flow-Prozess vertraut genug, um diesen speziellen Fall direkt mit Git-Befehlen zu behandeln.

— Bert F.
quelle

Wenn Sie den git flowProzess ändern , ist dies etwas anderes. Wenn ein Modell repariert (nicht nur erweitert) werden soll, ist es so erfolgreich, wie es der Autor angibt. Bitte lesen Sie meine Antwort auf das Thema, das wir diskutieren.

— Victor Yarema

0

git config --add gitflow.multi-hotfix true Dieser Befehl scheint für mich zu funktionieren!

— Laila
quelle