The current branching model only has a support branch where both dev-commits happen as well has an increase of the build metadata. The gitflow-documentation at https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/ shows how to solve this:
On the support branch, we create a hotfix branch ("hotfix/v2.1.1"). The hotfix branch follows the same logic as the develop branch:
The build metadata is updated to reflect the next (patch) version and has corresponding development pre-release information.
Pre-release branches for alpha and beta are created from and integrated back into the hotfix branch, same as on the develop branch. The tag is set on the pre-release branch.
Release branch is created from the hotfix branch and integrated back into both the hotfix branch and the support branch. The non-prerelease tag is set on the support branch.
When the release is performed, the hotfix branch is deleted and a new hotfix branch is created for the next patch version.
When creating a master merge, the script automatically creates a support branch and the first hotfix branch. (TODO: Create an extra Jira Ticket)
Note: We will continue to not use hotfix branches for the master, to make it easier to track the changes in a support branch and because there might be merge conflicts when trying to merge the master-hotfix into the develop as well.
Prerelease/Release and Hotfix Branches should be deleted locally after the branches are pushed
prerelease/release branches on support branches are not allowed/offered by the script
prerelease/release branches on hotfix branches are allowed/offered by the script
We should do a concept presentation before implementation starts to make sure all the details are understood and up to date.