it-swarm.com.de

Git-Flow und Master mit mehreren parallelen Release-Zweigen

Wir versuchen, das von git-flow implementierte erfolgreiches Git-Verzweigungsmodell zu übernehmen. Jetzt arbeiten wir an mindestens zwei Release-Zweigen, einem für die neueste stabile Version und einem für die nächste ("Vorschau") Version. Was ich nicht verstehe ist, warum alle Releases für den Master "linearisiert" und dort markiert scheinen. Warum nicht die Veröffentlichungen in ihren Veröffentlichungszweigen markieren? Warum überhaupt der Meister ? Oder warum ein Zweig entwickeln und nicht Master dafür verwenden?

73
Mot

Im Git-Flow-Modell ist Ihre "neueste veröffentlichte" Version tatsächlich dem master zugeordnet, während Ihre "Vorschau-Version" einem Git-Flow-Zweig release zugeordnet ist. Es wird von develop gespalten und schließlich zu master zusammengeführt, wenn die eigentliche Veröffentlichung erfolgt. Dann wird dies Ihre "neueste Version" und Sie beheben normalerweise nur Fehler für diese Version, indem Sie git-flow hotfixbranches verwenden. Auf diese Weise stellt Ihr master immer den stabilsten Status Ihrer neuesten veröffentlichten Version dar.

Wenn Sie Fehler für ältere Releases beheben oder dort eine andere Entwicklung durchführen möchten, werden Sie einen support -Zweig aus dem entsprechenden Commit in master abzweigen (Sie haben alle Versionen, die jemals dort erstellt wurden). support Zweige sind noch experimentell ( gemäß den Dokumenten ) und nicht gut dokumentiert. Aber wie Sie in der Befehlszeilenhilfe sehen können:

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

diese Zweige werden gerade gestartet und sollen nicht wieder zu master oder develop zusammengeführt werden. Dies ist normalerweise in Ordnung, da Korrekturen an "alten" Releases oder Funktionen, die von Kunden zur Implementierung in "alten" Releases angefordert wurden, nicht in master zurückgehen können oder sollten. Wenn Sie immer noch der Meinung sind, dass Sie einen Fix auf Ihre Hauptentwicklungslinie portieren möchten (dargestellt durch master und develop), starten Sie einfach ein hotfix, und wählen Sie Ihre Änderungen aus beende das hotfix.

66
mstrap

Sieht hauptsächlich nach einem mentalen Modell aus, bei dem der Schwerpunkt etwas zu stark auf Branchen liegt. Ich stimme zu, Sie könnten die von Ihnen freigegebenen Commits einfach markieren, anstatt sie wieder in master zusammenzuführen.

Das Bild ist jedoch hübsch. Wenn Sie alles wieder in Master zusammenführen, werden die Releases in zeitlicher Reihenfolge angezeigt, anstatt dass Versions-Tags im gesamten Diagramm verteilt sind.

Ich denke, dieses Modell funktioniert jedoch nicht für Bugfixes in älteren Releases. Es bringt die ordentliche Bestellung durcheinander.

  1. Angenommen, wir haben Version 1.0.1 veröffentlicht und später Funktionen hinzugefügt und 1.1.0 veröffentlicht.
  2. Wir haben einen Fehler in 1.0.1 entdeckt und möchten ihn in beiden Versionen beheben
  3. Wir müssen 1.0.2 nach 1.1.0 in master hinzufügen und dann auch 1.1.1 direkt ableiten (oder vorher).

Um Ihre Frage zu beantworten: Ich denke, dies ist ein Regelwerk, das in einigen Fällen zu einem einfachen mentalen Modell führt. Nicht alle Regeln sind rein technisch sinnvoll, aber das macht sie nicht schlecht. Mentale Modelle sind gut für die Menschen.

8
Sarien

Ich persönlich halte den erwähnten Git-Flow für überkompliziert.

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

Es ist besonders nützlich für die Zusammenarbeit bei mehreren Funktionen und für die Codeüberprüfung. Sie können es mit Ihrer Continuous Integration-Lösung kombinieren, indem Sie Commit Status API .

[~ # ~] Update [~ # ~] : Es gibt eine neue offizielle Website von The GitHub Flow ™

UPDATE 2 : Es gibt ein neues offizielles (und vereinfachtes) GitHub-Handbuch für The GitHub Flow ™: https: //guides.github. com/Introduction/Flow /

3
Haralan Dobrev

Stimme voll und ganz @Mot zu.

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

Unser Team war auch auf der Suche nach mehr universellen Verzweigungsmodellen als Erfolgreich eins. Das heißt Wie @Mot oben erwähnt - die Hauptidee ist es zu vermeiden, zusätzliche Repositorys zur Unterstützung von Release- * Zweigen in separaten * .git-Repositorys einzuführen, wie dies zum Beispiel bei stabilen Releases von kernel.org der Fall ist. 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 develop zu haben.

Es gibt auch einige Konflikte in release- * merging model to master und anschließend mit idea to

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

ursache Abschluss (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 automatischer Versionierungsunterstützung anfängt zu bauen:

$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 einige Bump-Version-Prozess einführt, aber es ist nicht automatisch.

Zusammenfassend sind die wichtigsten Unterschiede, die wir für das Zusammenführen und Markieren von Releases * in das Branch-Modell einführen, folgende: - Markierung der Release beim Erstellen des Branches - Beibehaltung des Branches des Releases, um diese in Zukunft warten zu können

1
mdn

In meinem Fall habe ich zwei Versionen der gleichen Software, die die gleichen Grundlagen haben, aber jede Version hat einige unterschiedliche Funktionen.

Also erstelle ich zwei worktree, dh erstelle zwei relevante Langzeitzweige 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 gemeinsamen Änderungen im Master vor. verschmelze es dann mit beiden anderen Versionen.

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 auch in den entsprechenden Ordner übernommen, und die Arbeiten an jedem Projekt werden isoliert und IDE nicht verwechselt.

Hoffentlich hilft das.

1
vaheeds