These examples are using the default configuration with
GitVersion. Which is
continuous deployment
mode for develop and
continuous delivery
mode for all other branches.
This default configuration allows you to publish CI builds from develop to a CI MyGet feed, or another CI feed. Then all other branches are manually released then tagged. Read more about this at version increments.
Feature Branches
Feature branches will take the feature branch name and use that as the pre-release tag.
Notice after the feature branch is merged, the version on
develop is 1.3.0-alpha.3. This is due to
develop running in continuous deployment mode.
If you configured develop to use
continuous delivery the version would still be
1.3.0-alpha.1 and you would have to use release tags to
increment the alpha.1.
You can see the difference on the feature branch itself, notice the
version is the same before and after the commit on the feature
branch? Only the metadata has changed. If you released the feature
branch artifacts then tagged the commit, the following commit would
increase to -beta.2.
Pull Request
Because feature branches are most likely pushed to a fork, we are showing the pull request branch name which is created when you submit a pull request
Hotfix Branches
Hotfix branches are used when you need to do a
patch release in GitFlow and are always created off
main
Minor Release Branches
Release branches are used for both major and minor releases for
stabilisation before a release. Release branches are taken off
develop then merged to both develop and
main. Finally main is tagged with the
released version.
Major Release Branches
Major releases are just like minor releases, the difference is you bump the major in the release branch name.
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)
Hotfix
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.
Minor Release
To Contribute
Source
See DocumentationSamples.GitFlowExample. To update,
modify then run test. Update
https://gist.github.com/JakeGinnivan/cf053d7f5d336ae9f7bb