docs(recipes): moved recipes to sub-directories to align with gitbook expectations (#2246)

docs/usage/ci-configuration.md

@@ -13,7 +13,7 @@ Here is a few example of the CI services that can be used to achieve this:
 - [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
 - [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).
 
-See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
+See [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details.
 
 ## Authentication
 
@@ -29,7 +29,7 @@ See [CI configuration recipes](../recipes/README.md#ci-configurations) for more
 | `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clearification `user:token` has to be the value of this env.        |
 | `GIT_CREDENTIALS`                                     | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `<username>:<password>`. The username and password must each be individually URL encoded, not the `:` separating them. |
 
-Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-auth-ssh-keys.md).
+Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-hosted-services/git-auth-ssh-keys.md).
 
 ### Authentication for plugins
 
@@ -44,6 +44,6 @@ See each plugin's documentation for the environment variables required.
 
 The authentication token/credentials have to be made available in the CI service via environment variables.
 
-See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on how to configure environment variables in your CI service.
+See [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on how to configure environment variables in your CI service.
 
 **Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).

docs/usage/workflow-configuration.md

@@ -6,7 +6,7 @@
 - Maintain multiple lines of releases in parallel
 - Work on large future releases outside the normal flow of one version increment per Git push
 
-See [Release workflow recipes](../recipes/README.md#release-workflow) for detailed examples.
+See [Release workflow recipes](../recipes/release-workflow/README.md#release-workflow) for detailed examples.
 
 The release workflow is configured via the [branches option](./configuration.md#branches) which accepts a single or an array of branch definitions.
 Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted.
@@ -108,7 +108,7 @@ A project must define a minimum of 1 release branch and can have a maximum of 3.
 
 **Note:** With **semantic-release** as with most package managers, a release version must be unique, independently of the distribution channel on which it is available.
 
-See [publishing on distribution channels recipe](../recipes/distribution-channels.md) for a detailed example.
+See [publishing on distribution channels recipe](../recipes/release-workflow/distribution-channels.md) for a detailed example.
 
 #### Pushing to a release branch
 
@@ -142,7 +142,7 @@ Maintenance branches are always considered lower than [release branches](#releas
 
 **semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only versions within the branch `range` can be merged. If a merged version is outside the maintenance branch `range`, **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error.
 
-See [publishing maintenance releases recipe](../recipes/maintenance-releases.md) for a detailed example.
+See [publishing maintenance releases recipe](../recipes/release-workflow/maintenance-releases.md) for a detailed example.
 
 #### Pushing to a maintenance branch
 
@@ -171,7 +171,7 @@ A pre-release branch is characterized by the `prerelease` property that defines
 
 When merging commits associated with an existing release, **semantic-release** will treat them as [pushed commits](#pushing-to-a-pre-release-branch) and publish a new release if necessary, but it will never add those releases to the distribution channel corresponding to the pre-release branch.
 
-See [publishing pre-releases recipe](../recipes/pre-releases.md) for a detailed example.
+See [publishing pre-releases recipe](../recipes/release-workflow/pre-releases.md) for a detailed example.
 
 #### Pushing to a pre-release branch