Git-Workflow Release-Branch vorteilhaft abschließen

[Martin (Gast)]

Hallo Leute!

Ich arbeite mich gerade in Git-Workflow ein.
Dabei ist mir aufgefallen, dass es für den Abschluss von 
Release-Branches zwei Möglichkeiten gibt:

1:
Release-Branch wird in den Master-Branch gemerged.
Anlegen eines Tags.
Release-Branch wird in den Develop-Branch gemerged.
Release-Branch löschen.

2:
Release-Branch wird in den Master-Branch gemerged.
Anlegen eines Tags.
Master-Branch wird in den Develop-Branch gemerged.
Release-Branch löschen.

Möglichkeit 1 wird in den meisten Dokus beschrieben. Doch das 
"git-flow"-Package unter Linux verwendet Möglichkeit 2. Wo liegen denn 
minunter hier die Vorteile bzw. Nachteile? Ich würde gerne, bevor ich 
meine Projekte in git einpflege, in Bezug darauf eine Entscheidung 
treffen können.

Vielen Dank im Voraus.

Schöne Grüße
Martin

[tictactoe (Gast)]

Ich gehe mal davon aus dass mit "Anlegen eines Tags" gemeint ist, auf 
dem Release-Branch einen Tag zu machen (denn das ist ja, was releast 
worden ist).

Am Ende von Methode 1 enthält der Develop-Branch alles, was auch im 
Release-Branch enthalten ist und zusätzlich auch alles vom 
Master-Branch. Develop und Master sind also nicht unabhängig.

Am Ende von Methode 2 sind Develop und Master weiterhin unabhängig. Man 
kann sich später noch überlegen, ob man denn alles was in Master ist, 
auch in Develop braucht. MMn ist Methode 2 zu bevorzugen, weil man 
danach noch mehr Freiheiten hat.

Ich selbst würde aber Methode 3 nehmen:

Anlegen eines Tags (am Release-Branch).
Release-Branch wird in den Master-Branch gemerged.

Der Develop-Branch kommt hier gar nicht ins Spiel. Erst wenn es 
notwendig wird, überlegt man sich, ob man für Develop nur Release 
braucht oder gleich den ganzen Master und handelt entsprechend.

Der Release-Branch wird nicht gelöscht, denn es könnten ja noch weitere 
Hot-Fixes notwendig werden.

Außerdem verwende ich Topic-Branches und merge immer nur die Topics 
(Develop1, Develop2, ...) nach Master und nicht umgekehrt. Aber das ist 
eine andere Geschichte.

[Dirk D. (dicky_d)]

Ich nehme an du meinst git-flow, richtig?

Nach Git flow gibt es zu keinem Zeitpunkt (wir ignorieren man das die 
git flow Kommandos nicht atomar sind) Commits auf Master die es nicht in 
Develop sind.

Daher ist es für das Ergebnis egal in welcher Reihenfolge und von wo die 
Commits in die passenden Branches kommen.

@tictactoe
Das von dir beschriebene Vorgehen ist dein Persönlicher git workflow, 
aber nicht git-flow, wie z.B. hier beschrieben: 
https://danielkummer.github.io/git-flow-cheatsheet/

Das spricht jetzt gar nicht gegen deinen Workflow, ich vermute aber das 
Martin nach git-flow gefragt hat.