Docs: Corrected terminology for local working copy

doc/ci/yaml/README.md

@@ -1246,8 +1246,8 @@ Read how caching works and find out some good practices in the
 [caching dependencies documentation](../caching/index.md).
 
 `cache` is used to specify a list of files and directories which should be
-cached between jobs. You can only use paths that are within the project
-workspace.
+cached between jobs. You can only use paths that are within the local working
+copy.
 
 If `cache` is defined outside the scope of jobs, it means it is set
 globally and all jobs will use that definition.
@@ -1417,7 +1417,7 @@ be available for download in the GitLab UI.
 
 #### `artifacts:paths`
 
-You can only use paths that are within the project workspace.
+You can only use paths that are within the local working copy.
 Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match).
 
 To pass artifacts between different jobs, see [dependencies](#dependencies).
@@ -2738,14 +2738,14 @@ 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.
+job, ensuring that the local working copy is always pristine.
 
 ```yaml
 variables:
   GIT_STRATEGY: clone
 ```
 
-`fetch` is faster as it re-uses the project workspace (falling back to `clone`
+`fetch` is faster as it re-uses the local working copy (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.
 
@@ -2754,11 +2754,11 @@ variables:
   GIT_STRATEGY: fetch
 ```
 
-`none` also re-uses the project workspace, but skips all Git operations
+`none` also re-uses the local working copy, 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.
+rely on files brought into the local working copy from cache or artifacts.
 
 ```yaml
 variables:

doc/user/project/pipelines/settings.md

@@ -21,8 +21,8 @@ from GitLab in a job.
 There are two options. Using:
 
 - `git clone`, which is slower since it clones the repository from scratch
-  for every job, ensuring that the project workspace is always pristine.
-- `git fetch`, which is faster as it re-uses the project workspace (falling
+  for every job, ensuring that the local working copy is always pristine.
+- `git fetch`, which is faster as it re-uses the local working copy (falling
   back to clone if it doesn't exist).
 
 The default Git strategy can be overridden by the [GIT_STRATEGY variable](../../../ci/yaml/README.md#git-strategy)