Wie behandelt Git-Flow Hotfixes für ältere Releases oder Point-Releases von älteren Releases?
Lesezeit: 3 Minuten
Wie geht Git Flow mit einem Hotfix um, nachdem der Master weit über diese Version hinausgegangen ist?
Szenario
Die Arbeit für 1.0 wurde am Entwicklungszweig durchgeführt, am Release-Zweig Releases/v1.0 stabilisiert und im Fast-Forward-Merge zum Master gepusht, wobei das Tag v1.0 auf die Spitze des Masters und die Spitze des Stabilisierungszweigs zeigt
Die Releases 1.1 – 3.2 finden auf die gleiche Weise statt.
Wir müssen einen Fehler in 1.0 beheben
Verzweigung vom v1.0-Tag
Behebung durchführen
wo zusammenführen?
Master liegt weit in der Zukunft und jede Zusammenführung wäre kein schneller Vorlauf und zum Spaß, sagen wir mal, es würde zu Konflikten kommen.
Würde ich zusammenführen, um den Stabilisierungszweig freizugeben und ein neues Tag zu erstellen? Würden nachfolgende Hotfixes das als Ausgangspunkt verwenden?
Das ist nicht der Fall, git glow geht davon aus, dass Sie nur eine einzige “Live” -Version haben.
– 1615903
4. Mai 2016 um 4:49 Uhr
Sie können jedoch jederzeit eine getaggte Version auschecken, dort einen neuen Hotfix-Zweig erstellen und wie gewohnt fortfahren.
– 1615903
4. Mai 2016 um 4:51 Uhr
Eigentlich denke ich, dass GitFlow besonders geeignet ist, um mit mehreren Versionen in freier Wildbahn umzugehen. Ich benutze es nur und empfehle es genau für “gepackte” SW (wo der Benutzer herunterlädt/installiert). Wenn es sich um das Web handelt (1 einzelne Live-Version), würde ich einen einfacheren Flow wie zum Beispiel GitHub Flow verwenden.
– Hugo Ferreira
4. Mai 2016 um 21:18 Uhr
Hugo Ferreira
nvies Abschnitt auf Hotfix-Zweige erklärt, das sind …
… sehr ähnlich wie Release-Zweige, da sie auch dazu gedacht sind, sich auf ein neues Produktions-Release vorzubereiten, wenn auch ungeplant.
Sie sollen also auf dem neuesten Stand gemacht werden master Version, wenn aktuelles Zeug reinkommt develop ist nicht bereit für das Normale release Kreislauf.
Was Sie hier zum Patchen einer älteren Version wollen, ist das Konzept von support Branches, das vor langer, langer Zeit diskutiert wurde, nachdem der anfängliche Git-Flow veröffentlicht wurde, aber afaik nie vollständig dokumentiert wurde.
Die gitflow-avh Das Tool scheint sie gut zu unterstützen, also sollten Sie es vielleicht in einem Test-Repo erkunden:
Ich habe einige Beiträge mit “Informationen” gefunden support Niederlassungen, war aber mit ihren Erklärungen nicht allzu zufrieden… angesichts des Mangels an Informationen über sie werde ich sie trotzdem verlinken:
Ich stimme zu, dass die Dokumentation zu den Support-Zweigen nicht existiert, vielleicht muss sogar die Dokumentation im Allgemeinen besser geschrieben werden. Mit git-flow AVH können Sie einen Hotfix aus einem Support-Zweig erstellen, und wenn Sie ihn fertigstellen, wird er wieder mit dem Support-Zweig zusammengeführt. Das Problem tritt auf, wenn Sie auch die anderen Versionen mit demselben Hotfix aktualisieren möchten. Dies müsste durch Patchen oder Rosinenpicken erfolgen. Für alle, die sich an dieser Diskussion beteiligen möchten, siehe das Problem auf github. github.com/petervanderdoes/gitflow-avh/issues/161
– Peter van der Does
5. Mai 2016 um 17:48 Uhr
Können Sie eine Liste von Git-Befehlen geben, um die Frage zu beantworten? Ich meine zu antworten “Wohin zusammenführen?” in der Frage. @PeterKahn hat ein bestimmtes Problem, könnten Sie also die entsprechende Lösung geben?
– FreeLightman
1. Dezember 2016 um 14:25 Uhr
@FreeLightman verschmelzen zu nirgendwo! 🙂 „Hotfix-Zweige“ sind hier nicht die Antwort und „Support-Zweige“ werden von einem Tag abgeleitet und bleiben ein lang laufender Zweig, bis die alte Version veraltet ist.
– Hugo Ferreira
15. Dezember 2016 um 14:05 Uhr
Nach Ihren Vorschlägen sind also Releases (in ihrem aktuellsten Zustand) sowohl Tags im Master-Branch als auch im Hotfix-Branch? Versuchen Sie, damit Schritt zu halten. Ich hätte lieber Konsistenz: Jede Veröffentlichung verzweigt sich, anstatt sie nur zu markieren. Dann ist es lästig, Hotfixes einer sehr alten Version weiterzugeben, aber zumindest ist es einfach, den HEAD jeder Version im Auge zu behalten.
– klar
22. Februar 2018 um 13:26 Uhr
@klaar in gitflow, Hotfix Branches sind kurzlebig, also die nur Definition eines Releases ist das Tag auf dem Master. Mit Hilfe von Support Branches zweigen Sie nur dann vom Master-Tag ab, wenn Sie eine ältere Version weiter hinten aktualisieren/warten/patchen müssen, die Sie genau auf ein Minimum beschränken möchten nicht mit der Unterstützung unterschiedlicher Codebasen Schritt halten zu müssen.
– Hugo Ferreira
23. Februar 2018 um 11:54 Uhr
14395300cookie-checkWie behandelt Git-Flow Hotfixes für ältere Releases oder Point-Releases von älteren Releases?yes
Das ist nicht der Fall, git glow geht davon aus, dass Sie nur eine einzige “Live” -Version haben.
– 1615903
4. Mai 2016 um 4:49 Uhr
Sie können jedoch jederzeit eine getaggte Version auschecken, dort einen neuen Hotfix-Zweig erstellen und wie gewohnt fortfahren.
– 1615903
4. Mai 2016 um 4:51 Uhr
Eigentlich denke ich, dass GitFlow besonders geeignet ist, um mit mehreren Versionen in freier Wildbahn umzugehen. Ich benutze es nur und empfehle es genau für “gepackte” SW (wo der Benutzer herunterlädt/installiert). Wenn es sich um das Web handelt (1 einzelne Live-Version), würde ich einen einfacheren Flow wie zum Beispiel GitHub Flow verwenden.
– Hugo Ferreira
4. Mai 2016 um 21:18 Uhr