Git-Release-Management

Ich konnte nichts finden, was der “richtige” Ansatz ist, um die Releases mit Git zu verwalten. Angenommen, ich habe Master-, Release-1-, Release-2- und Release-3-Zweige. Release 1 ist bereits veröffentlicht und ich behebe nur Fehler und markiere veröffentlichte Versionen darauf. Release 2 wird bald veröffentlicht und ich entwickle hauptsächlich auf diesem Zweig, während ich auf 3 Dinge entwickle, die in der weiteren Zukunft benötigt werden.

1. Wenn ich ein Feature zu Release-2 hinzufüge und es auch zu 3 gehen sollte, aber nicht zu 1, sollte ich:

   • Release-2 mit Master zusammenführen und Feature-bezogenes Cherry-Pick-Commit in Release-3 übernehmen?
   • Cherry-Pick-Feature-bezogenes Commit für Master und dann Cherry-Pick für Release-3?
   • etw sonst?

2. Wenn ich etw in allen Versionen ändern muss, sollte ich es auf dem Master tun und es für alle Zweige auswählen?

3. Sollte ich den Master auf dem neuesten Stand halten (Release-3-Zweig) oder lieber Entwickler auf Release-3 und mit dem Master zusammenführen, kurz bevor ich den Release-4-Zweig benötige?

4. Wenn ich etw auf Release-1 oder Release-2 behebe, sollte ich es dann zusammenführen oder aussuchen, um es zu meistern, oder eher?

Ich bin mir nicht ganz sicher, wann ich Rosinen auswählen soll, wann ich zusammenführen soll und ob der Fluss des Codes zwischen den Zweigen richtig ist.

Siehe die folgenden Beiträge im Blog von Junio ​​C Hamano (Git-Betreuer):

• Abschließen einer Zusammenführung
• Nie wieder verschmelzen (über Zweige, die mit der Absicht gegabelt wurden, nicht wieder zusammenzuführen)
• Konflikte/Abhängigkeiten zwischen Themenzweigen frühzeitig lösen
• Spaß mit entfernten Filialen (1)
• Spaß mit abgelegenen Filialen (2)

Schauen Sie sich auch an gitworkflows Handbuchseite.

Was Sie fragen, ist ein typisches a Workflow zusammenführen Problem: was von wo nach wo zusammenführen.

Aber Sie müssen auch bedenken, dass in einem DVCS auch eine Zusammenführung von beeinflusst wird Überlegungen zur Veröffentlichung (Werden diese Branches in lokale oder öffentliche Repositories verschoben?)

Insbesondere der “Master”-Zweig ist standardmäßig sichtbar, wenn jemand Ihr Repo klont, was bedeutet, dass er auf das verweisen sollte, was Sie für diesen Benutzer / Entwickler für am nützlichsten halten. (da andere Zweige standardmäßig nicht lokal referenziert werden)

1/ Wenn ich ein Feature zu Release-2 hinzufüge und es auch zu 3 gehen sollte, aber nicht zu 1

Sie können r2 tatsächlich mit Master zusammenführen, nachdem Sie eine Reihe von Commits an r2 vorgenommen haben, um die erforderlichen Entwicklungen zu erreichen. Auf diese Weise ist nur eine begrenzte Anzahl von Commits im Master sichtbar, wodurch ein „Commit-Cluttering“ vermieden wird.
Für r3 können Sie jedoch aus r2 heraussuchen, was Sie benötigen, wenn r3 gepusht und veröffentlicht wird. Andernfalls könnten Sie r3 auf r2 umbasieren. Siehe Frage „Git-Workflow und Rebase vs. Merge“.

2/ Wenn ich etw in allen Versionen ändern muss, sollte ich es auf dem Master tun und es für alle Zweige auswählen?

Sie sollten es auf r2 tun und dann auf Master und r1 und r3 zusammenführen. Auf diese Weise wird diesen Zweigen nur ein Commit hinzugefügt.

3/ Sollte ich den Master auf dem neuesten Stand halten (Release-3-Zweig) oder lieber Entwickler auf Release-3 und mit dem Master zusammenführen, kurz bevor ich den Release-4-Zweig benötige?

Es hängt davon ab, was Ihr anderer Kollege sehen soll, wenn er das Repo klont.
Aber von 1/ nehme ich an, dass Master r2 (aktuelle Entwicklung) und nicht r3 (zukünftiges, langfristiges Refactoring) darstellt.

4/ Wenn ich etw auf Release-1 oder Release-2 repariere, sollte ich es zusammenführen oder zum Mastern herauspicken oder eher?

• r1: Cherry-Pick: Nicht alles, was Sie an r1 reparieren, soll mit der aktuellen Entwicklung zusammengeführt werden.
  Eigentlich würde ich eher fröhlich r1 auf r2 fixieren, sicherstellen, dass dort alles funktioniert, und dann auf Master zusammenführen.
• r2: Zusammenführen. Wenn master r2 darstellt, reicht ein einfacher Merge.

Ich würde tun:

1) r2 mit master zusammenführen und dann master mit r3 (r3 sollte in der Lage sein, alle Änderungen an master zu akzeptieren)

2) Commit für r1, Merge mit r2, Merge r2 mit Master und Merge Master mit r3

3) Vielleicht sollten Sie anstelle von r3 master verwenden und nur auf Branch off r3 entwickeln, wenn die Veröffentlichung vorbereitet wird, und alle Änderungen hier in master (das wird die nächste Version sein) zusammenführen. Oder verwenden Sie “Master” und “Next”-Zweig als Linux.

4) Zum Master zusammenführen

Ich denke, das Zusammenführen ist sauberer als das Rosinenpicken und ich denke, Sie sollten nur Rosinenpicken, wenn Sie ein Feature oder einen Bugfix auf einen älteren Zweig zurückportieren müssen, den Sie nicht erwartet haben, als der Commit durchgeführt wurde (sonst Commit auf dem ältesten Branch/Release you wollen den Code auf).