Git-Flow und Master mit mehreren parallelen Release-Zweigen

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?

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.

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.

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/

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.

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

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.