Integrate code review remarks from asbjornu.

Author: HHobeck

docs/input/docs/learn/branching-strategies/gitflow/examples.md

@@ -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
 
@@ -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
 
@@ -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