Skip to content

Commit

Permalink
Integrate code review remarks from asbjornu.
Browse files Browse the repository at this point in the history
  • Loading branch information
@HHobeck
HHobeck committed May 31, 2024
1 parent b0c65f7 commit 7551cad
Showing 1 changed file with 58 additions and 33 deletions.
91 changes: 58 additions & 33 deletions docs/input/docs/learn/branching-strategies/gitflow/examples.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,53 +6,69 @@ RedirectFrom:
- docs/git-branching-strategies/gitflow-examples
---

These examples are illustrating the usage of the supported `GitFlow` workflow in GitVersion.
To enable this workflow, the build-in template [GitFlow/v1](/docs/workflows/GitFlow/v1.json) needs to be referenced in the configuration as following:
These examples are illustrating the usage of the supported `GitFlow` workflow
in GitVersion. To enable this workflow, the builtin template
[GitFlow/v1](/docs/workflows/GitFlow/v1.json) needs to be referenced in the
configuration as follows:
```yaml
workflow: GitFlow/v1
mode: ContinuousDelivery
```
Where
the [continuous deployment](/docs/reference/modes/continuous-deployment) mode for no branches,
the [continuous delivery](/docs/reference/modes/continuous-delivery) mode for `main`, `support` and `develop` branches and
the [manual deployment](/docs/reference/modes/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](/docs/reference/version-increments).

__Notice:__ 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 applying. In production context the _continuous deployment_ mode might be a better option when e.g.
the releasing process is automated or the commits are tagged by the pipeline automatically.
Where
the [continuous deployment][continuous-deployment] mode for no branches,
the [continuous delivery][continuous-delivery] mode for
`main`, `support` and `develop` branches and
the [manual deployment][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](/docs/reference/version-increments).

:::{.alert .alert-info}
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 environement. Feature branches will take the feature branch name and use that
as the pre-release label. Will be created from `develop`, `release`, `main`, `support` or `hotfix` 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

![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_FeatureFromMainBranch.png)

__Notice:__ 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 you configured `main` to use _continuous deployment_ the version would
be `2.0.0`.
:::{.alert .alert-info}
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

![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_FeatureFromDevelopBranch.png)

__Notice:__ After the feature branch is merged, the version on `develop` is
:::{.alert .alert-info}
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 you configure `develop` 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
`alpha.1`.
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.
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

Expand All @@ -64,9 +80,11 @@ Hotfix branches are used when you need to do a _patch_ release in the `GitFlow`

## 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 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.

### Create release branch

Expand All @@ -91,15 +109,22 @@ support minors use `support/<major>.<minor>.x` or `support/<major>.<minor>.0`.

![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_SupportBranch.png)

__Notice:__ 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.
:::{.alert .alert-info}
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

See [contributing examples](/docs/learn/branching-strategies/contribute-examples).

### Source

See `DocumentationSamplesForGitFlow.cs`. To update, modify then run test.
See `DocumentationSamplesForGitFlow.cs`. To update, modify then run test.

[continuous-deployment]: /docs/reference/modes/continuous-deployment
[continuous-delivery]: /docs/reference/modes/continuous-delivery
[manual-deployment]: /docs/reference/modes/manual-deployment

0 comments on commit 7551cad

Please sign in to comment.