Deployment und Release Branches¶

Deployment-Branches¶

Ein oder mehrere Deployment-Branches empfehlen sich, wenn ihr z.B. den Release-Zeitpunkt nicht selbst bestimmen könnt, wie bei einer iOS-Anwendung, die die App-Store-Validierung bestehen muss, oder wenn euch nur ein bestimmtes Zeitfenster für die Bereitstellung zur Verfügung steht. In diesen Fällen empfiehlt sich ein Deployment-Branch, der den bereitgestellten Code widerspiegelt. Ein solcher Arbeitsablauf verhindert dann zusätzliche Arbeitsaufwände bei Git rebase und Git-Tags.

Angenommen, ihr verfügt über eine development-, staging- und production-Umgebung, dann wird zunächst ein Merge- oder Pull-Request für eine Feature-Entwicklung beim staging-Branch gestellt. Sofern die Qualitätsprüfung dort bestanden wurde und der Code produktionsreif ist, können die Änderungen in den main-Branch übernommen werden. Dieser Vorgang kann sich für neue Features mehrfach wiederholen, bis z.B. der Zeitpunkt für das Going Live dieser Änderungen gekommen ist und ein Deployment-Branch erstellt werden kann.

Release-Branches¶

Wenn Software an Kunden geliefert werden soll, empfehlen sich sog. Release-Branches. In diesen Fällen sollte jeder Branch eine Minor Version erhalten, also z.B. 2.7 oder 3.10. Üblicherweise werden diese Branches so spät wie möglich aus dem main-Branch erzeugt um bei Bugfixes die Anzahl der Merges, die auf mehrere Branches verteilt werden müssen, zu reduzieren. Nachdem ein neuer Release-Branch erstellt wurde, erhält dieser nur noch Bugfixes. Meist werden diese zunächst in den main-Branch übernommen und kommen anschließend von dort mit Git Cherry-Pick in den Release-Branch, z.B.:

$ git switch 3.10
$ git cherry-pick 61de025
[3.10 b600967] Fix bug #17
 Date: Thu Sep 15 11:17:35 2022 +0200
 1 file changed, 9 insertions(+)

Dieser upstream first-Ansatz wird u.a. von Google und Red Hat verwendet. Jedes Mal, wenn ein Bugfix in einen Release-Branch übernommen wurde, wird das Release mit einem Git-Tags um eine Patch-Version angehoben, s.a. Semantic Versioning.