Merge branch '21337-introduce-git-strategy-none' into 'master'

Document GIT_STRATEGY=none

## What does this MR do?

Adds documentation for the new `GIT_STRATEGY=none` option in GitLab Runner v1.7

## Are there points in the code the reviewer needs to double check?

Speling and grammar, of course.

I'm using the term 'project workspace' to refer to the build directory, which is a Jenkins-ism. Is there preferred alternative wording?

## Why was this MR needed?

Discoverability of new feature

## Screenshots (if relevant)

## Does this MR meet the acceptance criteria?

- <strike>[ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added</strike>
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- <strike>[ ] API support added</strike>
- <strike>Tests</strike>
  - <strike>[ ] Added for this feature/bug</strike>
  - <strike>[ ] All builds are passing</strike>
- <strike>[ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)</strike>
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

Closes #21337 

Depends on http://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/332

See merge request !6577

doc/ci/yaml/README.md

@@ -858,27 +858,45 @@ job:
 
 ## Git Strategy
 
-> Introduced in GitLab 8.9 as an experimental feature. May change in future
-  releases or be removed completely.
+> Introduced in GitLab 8.9 as an experimental feature.  May change or be removed
+  completely in future releases. `GIT_STRATEGY=none` requires GitLab Runner
+  v1.7+.
 
-You can set the `GIT_STRATEGY` used for getting recent application code. `clone`
-is slower, but makes sure you have a clean directory before every build. `fetch`
-is faster. `GIT_STRATEGY` can be specified in the global `variables` section or
-in the `variables` section for individual jobs. If it's not specified, then the
-default from project settings will be used.
+You can set the `GIT_STRATEGY` used for getting recent application code, either
+in the global [`variables`](#variables) section or the [`variables`](#job-variables)
+section for individual jobs. If left unspecified, the default from project
+settings will be used.
+
+There are three possible values: `clone`, `fetch`, and `none`.
+
+`clone` is the slowest option. It clones the repository from scratch for every
+job, ensuring that the project workspace is always pristine.
 
 ```
 variables:
   GIT_STRATEGY: clone
 ```
 
-or
+`fetch` is faster as it re-uses the project workspace (falling back to `clone`
+if it doesn't exist). `git clean` is used to undo any changes made by the last
+job, and `git fetch` is used to retrieve commits made since the last job ran.
 
 ```
 variables:
   GIT_STRATEGY: fetch
 ```
 
+`none` also re-uses the project workspace, but skips all Git operations
+(including GitLab Runner's pre-clone script, if present). It is mostly useful
+for jobs that operate exclusively on artifacts (e.g., `deploy`). Git repository
+data may be present, but it is certain to be out of date, so you should only
+rely on files brought into the project workspace from cache or artifacts.
+
+```
+variables:
+  GIT_STRATEGY: none
+```
+
 ## Shallow cloning
 
 > Introduced in GitLab 8.9 as an experimental feature. May change in future