Deployment und Release Branches#
Deployment-Branches#
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 Production-Branch, der den bereitgestellten Code widerspiegelt. Ein solcher Arbeitsablauf verhindert dann zusätzliche Arbeitsaufwände bei Git rebase und Git-Tagging.
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, können die Änderungen 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 Life 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 checkout 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-Tagging um eine Patch-Version angehoben, s.a. Semantic Versioning.