These examples are illustrating the usage of the supported
GitFlow workflow in GitVersion. To enable this
workflow, the builtin template
GitFlow/v1 needs to be
referenced in the configuration as follows:
workflow: GitFlow/v1
mode: ContinuousDelivery
Where the
continuous deployment
mode for no branches, the
continuous delivery
mode for main, support and
develop branches and the
manual deployment
mode for release, feature,
hotfix and unknown branches are specified.
This configuration allows you to publish CI (Continuous Integration)
builds from main, support and
develop branches to an artifact repository. All other
branches are manually published. Read more about this at
version increments.
The continuous delivery mode has been used for the
main and the support branch in this
examples (specified as a fallback on the root configuration layer)
to illustrate how the version increments are applied. In
production context the continuous deployment mode might
be a better option when e.g. the release process is automated or
the commits are tagged by the pipeline automatically.
Feature Branches
Feature branches can be used in the GitFlow workflow to
implement a feature in an isolated environment. Feature branches
will take the feature branch name and use that as the pre-release
label. Feature branches will be created from a develop,
release, main, support or
hotfix branch.
Create feature branch from main
After the feature branch is merged, the version on
main is 2.0.0-5. This is due to
main running in continuous delivery mode. If
main was configured to use
continuous deployment the version would be
2.0.0.
Create feature branch from develop
After the feature branch is merged, the version on
develop is 1.3.0-alpha.3. This is due to
develop running in continuous delivery mode.
If develop was configured to use
manual deployment the version would still be
1.3.0-alpha.1 and you would have to use pre-release
tags to increment the pre-release label alpha.1.
Hotfix Branches
Hotfix branches are used when you need to do a
patch release in the GitFlow workflow and are
always created from main branch.
Create hotfix branch
Create hotfix branch with version number
Release Branches
Release branches are used for major and minor releases to stabilize
a RC (Release Candidate) or to integrate features (in parallel)
targeting different iterations. Release branches are taken from
main (or from develop) and will be merged
back afterwards. Finally the main branch is tagged with
the released version.
Release branches can be used in the GitFlow as well as
GitHubFlow workflow. Sometimes you want to start on a
large feature which may take a while to stabilize so you want to
keep it off main. In these scenarios you can either create a long
lived feature branch (if you do not know the version number this
large feature will go into, and it's non-breaking) otherwise you can
create a release branch for the next major version. You can then
submit pull requests to the long lived feature branch or the release
branch.
Create release branch
Create release branch with version
Develop Branch
Support Branches
Support branches are not really covered in GitFlow, but are
essential if you need to maintain multiple major versions at the
same time. You could use support branches for supporting minor
releases as well. If you are just supporting the majors, then name
your branch support/<major>.x (i.e
support/1.x), to support minors use
support/<major>.<minor>.x or
support/<major>.<minor>.0. (i.e
support/1.3.x or support/1.3.0)
Depending on what you name your support branch, you may or may not
need a hotfix branch. Naming it support/1.x will
automatically bump the patch, if you name it
support/1.3.0 then the version in branch name rule
will kick in and the patch will not automatically bump,
meaning you have to use hotfix branches.
To Contribute
Source
See DocumentationSamplesForGitFlow.cs. To update,
modify then run test.