Workflow auf Git bei der Arbeit mit parallelen Releases

Question

Wir verwenden das Konzept von Feature/Bugfix, entwickeln und veröffentlichen Zweige in Git und wir unterhalten keinen Master-Zweig.

Builds für QA und der endgültige Build für die Produktionsversion werden aus einem Versionszweig übernommen, während Snapshots vom Entwicklungszweig genommen werden.

sagen wir 2 Veröffentlichungen zur Zeit in Entwicklung haben:

Release 1 
Release 2 

Hauptproblem: Die Zusammenlegung der Änderungen Release 1-Release 2. Wir führen normalerweise eine große Zusammenführung durch, nachdem Release 1 in der Produktion eingesetzt wird. Dies führt zu mehreren Zusammenführungskonflikten.

Was ist der beste Workflow, um dies zu verhindern?

Eine Idee, die wir haben, ist, die Feature/Bugfix-Zweige von Release 1 mit den Entwicklungszweigen von Release 1 und Release 2 zusammenzuführen. Dies bedeutet jedoch zusätzliche Arbeit für die Entwickler.

Answer 1

Das Zusammenführen (Git Merge) von Release-Zweig ist in der Regel nicht die beste Vorgehensweise: einige Commits werden nur für ein Release durchgeführt und nicht für ein anderes Release.

Cherry-picking wird in der Regel zwischen zwei Zweigen durchgeführt, die keine Absicht haben, zusammengeführt zu werden (jeder Freisetzungszweig hat seine eigene unabhängige Historie).
Es wird immer noch Konflikte geben, aber zumindest ihre Herkunft ist leichter zu erkennen (es kommt das spezifische Commit, das ausgewählt wird).
Die gleiche Idee gilt für den Bug-Fix-Zweig (nicht alle Fixes gelten für den nächsten Release-Zweig, daher Rosinenpicken).
Ein Feature-Zweig konnte jedoch zusammengeführt werden.