Update capitalization in /integrations and /raketasks

Also updates redirect text in /project-services

4 files changed, 13 insertions, 13 deletions

diff --git a/doc/raketasks/README.md b/doc/raketasks/README.md
index dcc96507676..ad86555fc17 100644
--- a/doc/raketasks/README.md
+++ b/doc/raketasks/README.md
@@ -12,7 +12,7 @@ comments: false
 - [General Maintenance](../administration/raketasks/maintenance.md) and self-checks
 - [User management](user_management.md)
 - [Webhooks](web_hooks.md)
-- [Import](import.md) of git repositories in bulk
+- [Import](import.md) of Git repositories in bulk
 - [Rebuild authorized_keys file](../administration/raketasks/maintenance.md#rebuild-authorized_keys-file) task for administrators
 - [Migrate Uploads](../administration/raketasks/uploads/migrate.md)
 - [Sanitize Uploads](../administration/raketasks/uploads/sanitize.md)
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 19486052dd9..336000f6cb9 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -94,7 +94,7 @@ docker exec -t <container name> gitlab-backup create
 
 If you are using the [GitLab helm chart](https://gitlab.com/charts/gitlab) on a
 Kubernetes cluster, you can run the backup task using `backup-utility` script on
-the gitlab task runner pod via `kubectl`. Refer to [backing up a GitLab installation](https://gitlab.com/charts/gitlab/blob/master/doc/backup-restore/backup.md#backing-up-a-gitlab-installation) for more details:
+the GitLab task runner pod via `kubectl`. Refer to [backing up a GitLab installation](https://gitlab.com/charts/gitlab/blob/master/doc/backup-restore/backup.md#backing-up-a-gitlab-installation) for more details:
 
 ```sh
 kubectl exec -it <gitlab task-runner pod> backup-utility
@@ -458,7 +458,7 @@ You may also send backups to a mounted share (`NFS` / `CIFS` / `SMB` / etc.) by
 using the Fog [`Local`](https://github.com/fog/fog-local#usage) storage provider.
 The directory pointed to by the `local_root` key **must** be owned by the `git`
 user **when mounted** (mounting with the `uid=` of the `git` user for `CIFS` and
-`SMB`) or the user that you are executing the backup tasks under (for omnibus
+`SMB`) or the user that you are executing the backup tasks under (for Omnibus
 packages, this is the `git` user).
 
 The `backup_upload_remote_directory` **must** be set in addition to the
@@ -507,7 +507,7 @@ For installations from source:
 ### Backup archive permissions
 
 The backup archives created by GitLab (`1393513186_2014_02_27_gitlab_backup.tar`)
-will have owner/group git:git and 0600 permissions by default.
+will have owner/group `git`/`git` and 0600 permissions by default.
 This is meant to avoid other system users reading GitLab's data.
 If you need the backup archives to have different permissions you can use the 'archive_permissions' setting.
 
@@ -614,7 +614,7 @@ GitLab that you created it on, for example CE 9.1.0.
 
 You need to have a working GitLab installation before you can perform
 a restore. This is mainly because the system user performing the
-restore actions ('git') is usually not allowed to create or delete
+restore actions (`git`) is usually not allowed to create or delete
 the SQL database it needs to import data into ('gitlabhq_production').
 All existing data will be either erased (SQL) or moved to a separate
 directory (repositories, uploads).
@@ -773,14 +773,14 @@ In this case you can consider using filesystem snapshots as part of your backup
 
 Example: Amazon EBS
 
-> A GitLab server using omnibus-gitlab hosted on Amazon AWS.
+> A GitLab server using Omnibus GitLab hosted on Amazon AWS.
 > An EBS drive containing an ext4 filesystem is mounted at `/var/opt/gitlab`.
 > In this case you could make an application backup by taking an EBS snapshot.
 > The backup includes all repositories, uploads and Postgres data.
 
 Example: LVM snapshots + rsync
 
-> A GitLab server using omnibus-gitlab, with an LVM logical volume mounted at `/var/opt/gitlab`.
+> A GitLab server using Omnibus GitLab, with an LVM logical volume mounted at `/var/opt/gitlab`.
 > Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
 > Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
 > Now we can have a longer running rsync job which will create a consistent replica on the remote server.
@@ -804,7 +804,7 @@ will have all your repositories, but not any other data.
 
 ## Troubleshooting
 
-### Restoring database backup using omnibus packages outputs warnings
+### Restoring database backup using Omnibus packages outputs warnings
 
 If you are using backup restore procedures you might encounter the following warnings:
 
diff --git a/doc/raketasks/features.md b/doc/raketasks/features.md
index 57c16f110e4..c06800a2aa3 100644
--- a/doc/raketasks/features.md
+++ b/doc/raketasks/features.md
@@ -6,7 +6,7 @@ This command will enable the namespaces feature introduced in v4.0. It will move
 
 Note:
 
-- Because the **repository location will change**, you will need to **update all your git URLs** to point to the new location.
+- Because the **repository location will change**, you will need to **update all your Git URLs** to point to the new location.
 - Username can be changed at **Profile ➔ Account**.
 
 **Example:**
diff --git a/doc/raketasks/import.md b/doc/raketasks/import.md
index c76180a242e..d93e7241fda 100644
--- a/doc/raketasks/import.md
+++ b/doc/raketasks/import.md
@@ -13,7 +13,7 @@
 
 ### Create a new folder to import your Git repositories from
 
-The new folder needs to have git user ownership and read/write/execute access for git user and its group:
+The new folder needs to have Git user ownership and read/write/execute access for Git user and its group:
 
 ```
 sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
@@ -21,7 +21,7 @@ sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
 
 ### Copy your bare repositories inside this newly created folder
 
-- Any .git repositories found on any of the subfolders will be imported as projects
+- Any `.git` repositories found on any of the subfolders will be imported as projects
 - Groups will be created as needed, these could be nested folders. Example:
 
 If we copy the repos to `/var/opt/gitlab/git-data/repository-import-<date>`, and repo A needs to be under the groups G1 and G2, it will
@@ -34,7 +34,7 @@ sudo cp -r /old/git/foo.git /var/opt/gitlab/git-data/repository-import-<date>/ne
 sudo chown -R git:git /var/opt/gitlab/git-data/repository-import-<date>
 ```
 
-`foo.git` needs to be owned by the git user and git users group.
+`foo.git` needs to be owned by the `git` user and `git` users group.
 
 If you are using an installation from source, replace `/var/opt/gitlab/` with `/home/git`.
 
@@ -96,7 +96,7 @@ Importing bare repositories from hashed storage is unsupported.
 
 To support importing bare repositories from hashed storage, GitLab 10.4 and
 later stores the full project path with each repository, in a special section of
-the git repository's config file. This section is formatted as follows:
+the Git repository's config file. This section is formatted as follows:
 
 ```
 [gitlab]