Git-Flow und Master mit mehreren parallelen Release-Zweigen

86

Wir versuchen, das erfolgreiche Git-Verzweigungsmodell zu übernehmen, das von git-flow implementiert wird. Derzeit arbeiten wir an mindestens zwei Release-Zweigen, einem für das neueste stabile Release und einem für das nächste ("Vorschau") Release. Was ich nicht verstehe ist, warum alle Releases für den Master "linearisiert" und dort markiert sind. Warum markieren Sie die Releases nicht in ihren Release-Zweigen? Warum überhaupt der Meister ? Oder warum einen Entwicklungszweig und keinen Master dafür verwenden?

Mot
quelle

Antworten:

77

Im Git-Flow-Modell wird Ihre "neueste Version" tatsächlich der Version zugeordnet master, während Ihre "Vorschau-Version" einem Git-Flow- releaseZweig zugeordnet wird. Es wird gegabelt developund schließlich zusammengeführt, masterwenn die eigentliche Veröffentlichung erfolgt. Dann wird dies Ihre "neueste Version" und Sie werden normalerweise nur Fehler für diese Version mithilfe von Git-Flow- hotfixZweigen beheben . Auf diese Weise stellt Ihr masterimmer den stabilsten Status Ihrer neuesten veröffentlichten Version dar.

Wenn Sie Fehler für ältere Releases beheben oder andere Entwicklungen dort durchführen möchten, wird ein supportZweig aus dem entsprechenden Commit in gegabelt master(Sie haben alle Versionen, die jemals dort erstellt wurden). supportZweige sind noch experimentell ( gemäß den Dokumenten ) und nicht gut dokumentiert. Aber wie Sie in der Befehlszeile sehen können, helfen Sie:

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

Diese Zweige werden gerade erst gestartet und sollen nicht zu masternoch zusammengeführt werden develop. Dies ist normalerweise in Ordnung, da Korrekturen an "alten" Versionen oder Funktionen, die von Kunden zur Implementierung in "alten" Versionen angefordert wurden, nicht verwendet werden können oder sollten master. Wenn Sie immer noch der Meinung sind, dass Sie einen Fix auf Ihre Hauptentwicklungslinie (dargestellt durch masterund develop) portieren möchten , starten Sie einfach a hotfix, wählen Sie Ihre Änderungen aus und beenden Sie den Vorgang hotfix.

mstrap
quelle
17
Dies betrifft keine langsame Pipeline vom Test über die Qualitätssicherung bis zur Produktion. Möglicherweise sind zwei (oder sogar mehr, aber sagen wir vorerst zwei) Release-Zweige geöffnet, die sich jeweils in einer anderen Phase dieser Pipeline befinden und jeweils erforderlich sind, um Korrekturen für im Test gefundene Fehler zu ermöglichen. In der Entwicklungsniederlassung würden dann Features für eine Version gesammelt, deren Verzweigung noch nicht erstellt wurde. In einer solchen Situation würde ein Fix für Release n-2 schließlich zusammengeführt, um sich zu entwickeln, würde jedoch Release n-1 zumindest nach dem Standard-Git-Flow überspringen. Dies würde zu einer Regression auf n-1 führen, die schließlich auf Release n
Brendan am
Warum sollten Release-Zweige nicht beibehalten werden und sobald ein neuerer Release-Zweig erstellt wurde, entwickeln sich ältere zu einem "Support" -Zweig?
lkanab
1
Warum werden Release-Zweige von der Entwicklung "gegabelt" und nicht nur von der Entwicklung "abgezweigt"?
Sandra K
gitflow-avh sieht aus wie eine gewartete (dh nicht tote) Gabel des ursprünglichen Gitflow. git flow supportist nicht experimentell markiert.
Timo Verhoeven
9

Sieht meistens wie ein mentales Modell aus, bei dem die Zweige etwas zu stark betont werden. Ich bin damit einverstanden, dass Sie die von Ihnen freigegebenen Commits einfach markieren können, anstatt sie wieder mit dem Master zusammenzuführen.

Das Bild ist allerdings hübsch. Wenn Sie alles wieder in Master zusammenführen, erhalten Sie einen klaren Hinweis auf die Releases in zeitlicher Reihenfolge, anstatt Versions-Tags über das gesamte Diagramm zu verteilen.

Ich denke, dieses Modell funktioniert jedoch nicht zur Fehlerbehebung in älteren Versionen. Es bringt die ordentliche Bestellung durcheinander.

  1. Angenommen, wir haben Version 1.0.1 und höher veröffentlicht und Funktionen hinzugefügt und 1.1.0 veröffentlicht.
  2. Wir entdecken einen Fehler in 1.0.1 und möchten ihn in beiden Versionen beheben
  3. Wir müssen 1.0.2 nach 1.1.0 im Master hinzufügen und dann direkt (oder vorher) auch 1.1.1 hinzufügen.

Um Ihre Frage zu beantworten: Ich denke, dies ist ein Regelwerk, das in einigen Fällen ein einfaches mentales Modell darstellt. Nicht alle Regeln sind aus rein technischer Sicht sinnvoll, aber das macht sie nicht schlecht. Mentale Modelle sind gut für sie Menschen.

Sarien
quelle
1
supportZweige wurden zur Fehlerbehebung in älteren Versionen entwickelt, obwohl sie immer noch als "experimentell" gekennzeichnet sind.
Mstrap
2

Ich persönlich denke, der erwähnte Git-Flow ist zu kompliziert.

Wenn Sie GitHub verwenden, versuchen Sie das GitHub flow(wie von Scott Chacon beschrieben).

Es ist besonders nützlich für die Zusammenarbeit bei mehreren Funktionen, die Codeüberprüfung und die Kombination mit Ihrer Continuous Integration-Lösung mithilfe von Commit Status API.

UPDATE : Es gibt eine neue offizielle Website von The GitHub Flow ™

UPDATE 2 : Es gibt einen neuen offiziellen (und vereinfachten) GitHub-Leitfaden für The GitHub Flow ™: https://guides.github.com/introduction/flow/

Haralan Dobrev
quelle
10
Der GitHub-Flow ist nur für einen nicht Release-zentrierten Kontext geeignet: Der Git-Flow-Prozess ist weitgehend auf das "Release" ausgelegt. Wir haben nicht wirklich "Releases", da wir jeden Tag - oft mehrmals am Tag - für die Produktion bereitstellen.
Remi Mélisson
10
Ich würde auch hinzufügen, dass Git-Flow in einem Release-zentrierten Kontext mit Wartungs-Releases nicht wirklich gut funktioniert . Was passiert beispielsweise, wenn eine Version 1.2.1 nach einer Version 1.3.0 erfolgt? Es kann vermutlich nicht zu mastereiner Anomalie der Chronologie des Werkes zusammengeführt werden.
Ken Williams
@ KenWilliams wie in der Antwort von mstrap beschrieben , dafür sind supportZweige gedacht . Aber Sie haben Recht, es ist in der Tat eine Anomalie, dass solche Releases nicht wieder zusammengeführt werden master, was nach meinem Verständnis alle Produktions-Releases enthalten sollte.
beatngu13
2

In meinem Fall habe ich zwei Versionen derselben Software, deren Grundlagen identisch sind, aber jede Version hat einige unterschiedliche Funktionen.

Also erstelle ich zwei worktree, das heißt, ich erstelle zwei relevante, lang laufende Zweige neben dem Master.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Dann habe ich:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Es gibt ein Repository, aber ich habe 3 separate Ordner nebeneinander für jeden Zweig oben. Und nehmen Sie die allgemeinen Änderungen im Master vor. Führen Sie es dann mit beiden anderen Versionen zusammen.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Spezifische Änderungen jeder Version werden ebenfalls in den entsprechenden Ordner übernommen, und die Arbeiten an jedem Projekt sind isoliert, und die IDE wird nicht verwechselt.

Hoffentlich hilft das.

Vaheeds
quelle
2

Stimme voll und ganz @Mot zu.

Es ist schön, die gleichen Fragen zu hören.

Unser Team wurde auch nach mehr Universal-Verzweigungsmodellen als nach Successfull gesucht. Dh wie oben erwähnt @Mot - die Hauptidee besteht darin, die Einführung zusätzlicher Repositorys zur Unterstützung von Release- * -Zweigen in separaten * .git-Repos zu vermeiden, wie dies beispielsweise von kernel.org für stabile Releases durchgeführt wird. Aber kernel.org tut es, um die heruntergeladenen Größen zu minimieren, denke ich.

Für mich scheint es sauberer zu sein, Master als Hauptlinie für die Entwicklung zu haben .

Es gibt auch einige Konflikte beim Release- * Zusammenführen des Modells, um es zu meistern und anschließend mit der Idee zu versehen

Verwenden Sie ein Git-Hook-Skript, um unsere Software jedes Mal automatisch zu erstellen und auf unseren Produktionsservern bereitzustellen, wenn ein Commit für den Master durchgeführt wurde

Das Finishing (Zusammenführen und Markieren) ist keine atomare Transaktion:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

und wenn git hook mit Unterstützung für die automatische Versionierung erstellt wird:

$git describe --tags --long >.ver

dann kann eine fehlerhafte Version erstellt werden für:

$ git merge --no-ff release-1.2

Ich weiß, dass die Versionierung in Successfull One einen Bump-Version-Prozess einführt , aber nicht automatisch.

Zusammenfassend lässt sich sagen, dass die wichtigsten Unterschiede, die wir beim Verzweigungsmodell für Releases * zum Zusammenführen und Markieren einführen, folgende sind: - Kennzeichnen von Releases beim Erstellen des Zweigs - Beibehalten des Zweigs des Releases, um die zukünftige Wartung zu ermöglichen

mdn
quelle
-2

Der Hauptzweig sollte IMMER Ihre Produktionscodebasis darstellen, daher führen Sie den Code immer direkt nach einer Produktionsfreigabe wieder zum Master zusammen.

Das Tagging wird verwendet, um den genauen Code zu "merken", der in einer Produktionsversion enthalten war, sodass Sie später zurückgehen und den Code analysieren können, wenn ein Fehler aufgetreten ist.

Theoretisch sollte es keine Rolle spielen, ob Sie Ihren Code im Release-Zweig oder im Master-Zweig markieren, nachdem Sie ihn wieder mit dem Master zusammengeführt haben. Ich persönlich bevorzuge es, den Code im Release-Zweig zu markieren, da dies genau der Code ist, der in den Build / Release eingefügt wurde (vorausgesetzt, bei der Zusammenführung kann etwas schief gehen).

Das Problem mit dem Entwicklungszweigkonzept ist, dass es Single-Threaded ist. Brendan erwähnte in diesem Thread eine Strategie, die mit einem Entwicklungszweigkonzept angewendet werden könnte.

Bernie Lenz
quelle
4
Was ist eine "Produktionscodebasis", wenn Sie mehrere Releases verwalten, z. B. v1.0, v1.1, v1.5 parallel?
Thomas S.
Production Code Base ist das, was gerade in der Produktion ist, z. B. v1.0. Die Niederlassungen enthalten Änderungen für Releases, die in Zukunft für die Produktion bereitgestellt werden sollen, z. B. V1.0.1, v1.1 und v2.0. Sobald eine "zukünftige" Version für die Produktion bereitgestellt wurde, wird sie wieder zum Master zusammengeführt, sodass der Master die Produktion widerspiegelt. Es wird auch vorwärts zusammengeführt (z. B. v1.0.1 bis 1.1 und v2.0), damit die Änderungen an v1.0.1 nicht verloren gehen, wenn v1.1 für die Produktion freigegeben wird.
Bernie Lenz
4
Ich spreche über die Pflege mehrerer veröffentlichter Versionen, nicht über zukünftige Versionen.
Thomas S.
4
Du scheinst mich nicht zu verstehen. Können Sie sich nicht vorstellen, dass in einigen Unternehmen mehrere Release-Versionen beibehalten werden? Microsoft verwaltet beispielsweise auch Updates für Windows 7, 8, 8.1 und 10. Warum also nicht andere Unternehmen?
Thomas S.
1
Das ist richtig, Thomas. Dieses Modell ist auf Produkte ausgerichtet, die zu einem bestimmten Zeitpunkt eine einzige Produktionsversion haben, z. B. Websites. Ich habe dieses Modell auch für mobile Builds verwendet, z. B. für Android und iPhone, bei denen der Build so parametrisiert ist, dass entweder ein Android- oder ein iPhone-Build (oder beides) mit derselben Versionsnummer erstellt wird. Ich bin gespannt auf Ihre Beiträge zur Strukturierung eines Build-Modells für ein Produkt, das zu einem bestimmten Zeitpunkt mehrere Live-Versionen in Produktion hat, möglicherweise mit einigen gemeinsam genutzten und einigen unterschiedlichen Komponenten. Bitte lassen Sie es uns wissen ...
Bernie Lenz