Deployment and release branches#
We recommend one or more deployment branches if, for example, you cannot determine the release time
yourself, for example if an iOS application has to pass the app store validation
or you only have a fixed time window available for deployment. In this case, a
prod, that reflects the code provided is recommended. Such
a workflow prevents the additional work when using Git rebase and Git tags.
Assuming that you have a
environment, then a merge or pull request for a feature is first made to the
staging branch. As long as the quality check has been passed there, the
changes and the code can be ready for production, the changes can be transferred
main branch. This process can be repeated several times for new
features until for example the time has come for the going life of these
changes and a deployment branch can be created.
Release branches are recommended when software is to be delivered to customers.
In this case each branch should contain a minor version, for example
3.4. Usually these branches are created from the
main branch as late
as possible. This reduces the number of merges that have to be distributed
across multiple branches during bug fixes. Usually, these are first transferred
main and then transferred from there to the release branch with
Git cherry-pick, for example:
$ 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(+)
This upstream first approach is for example used by Google and Red Hat. Every time a bug fix has been adopted in a release branch, the release is increased by a patch version with a Tag, see also Semantic Versioning.