mikrocontroller.net

Forum: PC-Programmierung Git-Workflow Release-Branch vorteilhaft abschließen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: tictactoe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk D. (dicky_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.