Add markdownlint (#20512)

Add `markdownlint` linter and fix issues. Config is based on the one
from electron's repo with a few rules relaxed.

12 files changed, 62 insertions, 50 deletions

diff --git a/docs/content/doc/installation/database-preparation.en-us.md b/docs/content/doc/installation/database-preparation.en-us.md
index 13a215d814..b8ad5d6859 100644
--- a/docs/content/doc/installation/database-preparation.en-us.md
+++ b/docs/content/doc/installation/database-preparation.en-us.md
@@ -27,13 +27,13 @@ Note: All steps below requires that the database engine of your choice is instal
 
 ## MySQL
 
-1.  For remote database setup, you will need to make MySQL listen to your IP address. Edit `bind-address` option on `/etc/mysql/my.cnf` on database instance to:
+1. For remote database setup, you will need to make MySQL listen to your IP address. Edit `bind-address` option on `/etc/mysql/my.cnf` on database instance to:
 
     ```ini
     bind-address = 203.0.113.3
     ```
 
-2.  On database instance, login to database console as root:
+2. On database instance, login to database console as root:
 
     ```
     mysql -u root -p
@@ -41,7 +41,7 @@ Note: All steps below requires that the database engine of your choice is instal
 
     Enter the password as prompted.
 
-3.  Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance.
+3. Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance.
 
     For local database:
 
@@ -61,7 +61,7 @@ Note: All steps below requires that the database engine of your choice is instal
 
     Replace username and password above as appropriate.
 
-4.  Create database with UTF-8 charset and collation. Make sure to use `utf8mb4` charset instead of `utf8` as the former supports all Unicode characters (including emojis) beyond _Basic Multilingual Plane_. Also, collation chosen depending on your expected content. When in doubt, use either `unicode_ci` or `general_ci`.
+4. Create database with UTF-8 charset and collation. Make sure to use `utf8mb4` charset instead of `utf8` as the former supports all Unicode characters (including emojis) beyond _Basic Multilingual Plane_. Also, collation chosen depending on your expected content. When in doubt, use either `unicode_ci` or `general_ci`.
 
     ```sql
     CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';
@@ -69,7 +69,7 @@ Note: All steps below requires that the database engine of your choice is instal
 
     Replace database name as appropriate.
 
-5.  Grant all privileges on the database to database user created above.
+5. Grant all privileges on the database to database user created above.
 
     For local database:
 
@@ -85,9 +85,9 @@ Note: All steps below requires that the database engine of your choice is instal
     FLUSH PRIVILEGES;
     ```
 
-6.  Quit from database console by `exit`.
+6. Quit from database console by `exit`.
 
-7.  On your Gitea server, test connection to the database:
+7. On your Gitea server, test connection to the database:
 
     ```
     mysql -u gitea -h 203.0.113.3 -p giteadb
@@ -99,13 +99,13 @@ Note: All steps below requires that the database engine of your choice is instal
 
 ## PostgreSQL
 
-1.  For remote database setup, configure PostgreSQL on database instance to listen to your IP address by editing `listen_addresses` on `postgresql.conf` to:
+1. For remote database setup, configure PostgreSQL on database instance to listen to your IP address by editing `listen_addresses` on `postgresql.conf` to:
 
     ```ini
     listen_addresses = 'localhost, 203.0.113.3'
     ```
 
-2.  PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
+2. PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
 
     ```ini
     password_encryption = scram-sha-256
@@ -113,13 +113,13 @@ Note: All steps below requires that the database engine of your choice is instal
 
     Restart PostgreSQL to apply the setting.
 
-3.  On the database server, login to the database console as superuser:
+3. On the database server, login to the database console as superuser:
 
     ```
     su -c "psql" - postgres
     ```
 
-4.  Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below:
+4. Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below:
 
     ```sql
     CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
@@ -127,7 +127,7 @@ Note: All steps below requires that the database engine of your choice is instal
 
     Replace username and password as appropriate.
 
-5.  Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content:
+5. Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content:
 
     ```sql
     CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
@@ -135,7 +135,7 @@ Note: All steps below requires that the database engine of your choice is instal
 
     Replace database name as appropriate.
 
-6.  Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`.
+6. Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`.
 
     For local database:
 
@@ -155,7 +155,7 @@ Note: All steps below requires that the database engine of your choice is instal
 
     Restart PostgreSQL to apply new authentication rules.
 
-7.  On your Gitea server, test connection to the database.
+7. On your Gitea server, test connection to the database.
 
     For local database:
 
@@ -188,13 +188,13 @@ If the communication between Gitea and your database instance is performed throu
 
 The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate.
 
-1.  On the server with the database instance, place the following credentials:
+1. On the server with the database instance, place the following credentials:
 
     - `/path/to/postgresql.crt`: Database instance certificate
     - `/path/to/postgresql.key`: Database instance private key
     - `/path/to/root.crt`: CA certificate chain to validate client certificates
 
-2.  Add following options to `postgresql.conf`:
+2. Add following options to `postgresql.conf`:
 
     ```ini
     ssl = on
@@ -204,14 +204,14 @@ The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both d
     ssl_min_protocol_version = 'TLSv1.2'
     ```
 
-3.  Adjust credentials ownership and permission, as required by PostgreSQL:
+3. Adjust credentials ownership and permission, as required by PostgreSQL:
 
     ```
     chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
     chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
     ```
 
-4.  Edit `pg_hba.conf` rule to only allow Gitea database user to connect over SSL, and to require client certificate verification.
+4. Edit `pg_hba.conf` rule to only allow Gitea database user to connect over SSL, and to require client certificate verification.
 
     For PostgreSQL 12:
 
@@ -227,9 +227,9 @@ The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both d
 
     Replace database name, user, and IP address of Gitea instance as appropriate.
 
-5.  Restart PostgreSQL to apply configurations above.
+5. Restart PostgreSQL to apply configurations above.
 
-6.  On the server running the Gitea instance, place the following credentials under the home directory of the user who runs Gitea (e.g. `git`):
+6. On the server running the Gitea instance, place the following credentials under the home directory of the user who runs Gitea (e.g. `git`):
 
     - `~/.postgresql/postgresql.crt`: Database client certificate
     - `~/.postgresql/postgresql.key`: Database client private key
@@ -237,14 +237,14 @@ The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both d
 
     Note: Those file names above are hardcoded in PostgreSQL and it is not possible to change them.
 
-7.  Adjust credentials, ownership and permission as required:
+7. Adjust credentials, ownership and permission as required:
 
     ```
     chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
     chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
     ```
 
-8.  Test the connection to the database:
+8. Test the connection to the database:
 
     ```
     psql "postgres://gitea@example.db/giteadb?sslmode=verify-full"
@@ -258,13 +258,13 @@ While the MySQL driver used by Gitea also supports two-way TLS, Gitea currently
 
 In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn't take place.
 
-1.  On the database instance, place the following credentials:
+1. On the database instance, place the following credentials:
 
     - `/path/to/mysql.crt`: Database instance certificate
     - `/path/to/mysql.key`: Database instance key
     - `/path/to/ca.crt`: CA certificate chain. This file isn't used on one-way TLS, but is used to validate client certificates on two-way TLS.
 
-2.  Add following options to `my.cnf`:
+2. Add following options to `my.cnf`:
 
     ```ini
     [mysqld]
@@ -274,16 +274,16 @@ In one-way TLS, the database client verifies the certificate sent from server du
     tls-version = TLSv1.2,TLSv1.3
     ```
 
-3.  Adjust credentials ownership and permission:
+3. Adjust credentials ownership and permission:
 
     ```
     chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
     chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
     ```
 
-4.  Restart MySQL to apply the setting.
+4. Restart MySQL to apply the setting.
 
-5.  The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
+5. The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
 
     ```sql
     DROP USER 'gitea'@'192.0.2.10';
@@ -294,9 +294,9 @@ In one-way TLS, the database client verifies the certificate sent from server du
 
     Replace database user name, password, and Gitea instance domain as appropriate.
 
-6.  Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
+6. Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
 
-7.  On the server running Gitea, test connection to the database:
+7. On the server running Gitea, test connection to the database:
 
     ```
     mysql -u gitea -h example.db -p --ssl
diff --git a/docs/content/doc/installation/from-binary.en-us.md b/docs/content/doc/installation/from-binary.en-us.md
index c598317b6e..91a6b2a9d6 100644
--- a/docs/content/doc/installation/from-binary.en-us.md
+++ b/docs/content/doc/installation/from-binary.en-us.md
@@ -32,6 +32,7 @@ chmod +x gitea
 ```
 
 ## Verify GPG signature
+
 Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries.
 To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the GPG command line tool.
 
@@ -89,11 +90,11 @@ chmod 640 /etc/gitea/app.ini
 
 If you don't want the web installer to be able to write to the config file, it is possible to make the config file read-only for the Gitea user (owner/group `root:git`, mode `0640`) however you will need to edit your config file manually to:
 
- * Set `INSTALL_LOCK= true`,
- * Ensure all database configuration details are set correctly 
- * Ensure that the `SECRET_KEY` and `INTERNAL_TOKEN` values are set. (You may want to use the `gitea generate secret` to generate these secret keys.)
- * Ensure that any other secret keys you need are set.
- 
+* Set `INSTALL_LOCK= true`,
+* Ensure all database configuration details are set correctly
+* Ensure that the `SECRET_KEY` and `INTERNAL_TOKEN` values are set. (You may want to use the `gitea generate secret` to generate these secret keys.)
+* Ensure that any other secret keys you need are set.
+
 See the [command line documentation]({{< relref "doc/usage/command-line.en-us.md" >}}) for information on using `gitea generate secret`.
 
 ### Configure Gitea's working directory
diff --git a/docs/content/doc/installation/from-package.en-us.md b/docs/content/doc/installation/from-package.en-us.md
index 56ca97a8a5..3f75f26a53 100644
--- a/docs/content/doc/installation/from-package.en-us.md
+++ b/docs/content/doc/installation/from-package.en-us.md
@@ -53,7 +53,7 @@ snap install gitea
 
 ## SUSE and openSUSE
 
-OpenSUSE build service provides packages for [openSUSE and SLE](https://software.opensuse.org/download/package?package=gitea&project=devel%3Atools%3Ascm) 
+OpenSUSE build service provides packages for [openSUSE and SLE](https://software.opensuse.org/download/package?package=gitea&project=devel%3Atools%3Ascm)
 in the Development Software Configuration Management Repository
 
 ## Windows
diff --git a/docs/content/doc/installation/from-source.en-us.md b/docs/content/doc/installation/from-source.en-us.md
index 54e79769ea..660f996b1e 100644
--- a/docs/content/doc/installation/from-source.en-us.md
+++ b/docs/content/doc/installation/from-source.en-us.md
@@ -101,7 +101,7 @@ Depending on requirements, the following build tags can be included.
 - `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can
   be used to authenticate local users or extend authentication to methods
   available to PAM.
-* `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
+- `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
 
 Bundling assets into the binary using the `bindata` build tag is recommended for
 production deployments. It is possible to serve the static assets directly via a reverse proxy,
diff --git a/docs/content/doc/installation/from-source.fr-fr.md b/docs/content/doc/installation/from-source.fr-fr.md
index 4afbd13773..00f67eab55 100644
--- a/docs/content/doc/installation/from-source.fr-fr.md
+++ b/docs/content/doc/installation/from-source.fr-fr.md
@@ -30,7 +30,6 @@ cd $GOPATH/src/code.gitea.io/gitea
 
 Maintenant, il est temps de décider quelle version de Gitea vous souhaitez compiler et installer. Actuellement, ils existent plusieurs options possibles. Si vous voulez compiler notre branche `master`, vous pouvez directement passer à la [section compilation](#compilation), cette branche représente la dernière version en cours de développement et n'a pas vocation à être utiliser en production.
 
-
 Si vous souhaitez compiler la dernière version stable, utilisez les étiquettes ou les différentes branches disponibles. Vous pouvez voir les branches disponibles et comment utiliser cette branche avec ces commandes:
 
 ```
diff --git a/docs/content/doc/installation/from-source.zh-cn.md b/docs/content/doc/installation/from-source.zh-cn.md
index 7d08033603..275b0c2f74 100644
--- a/docs/content/doc/installation/from-source.zh-cn.md
+++ b/docs/content/doc/installation/from-source.zh-cn.md
@@ -26,7 +26,7 @@ go get -d -u code.gitea.io/gitea
 cd $GOPATH/src/code.gitea.io/gitea
 ```
 
-然后你可以选择编译和安装的版本，当前你有多个选择。如果你想编译 `master` 版本，你可以直接跳到 [编译](#build) 部分，这是我们的开发分支，虽然也很稳定但不建议您在正式产品中使用。
+然后你可以选择编译和安装的版本，当前你有多个选择。如果你想编译 `master` 版本，你可以直接跳到 [编译](#编译) 部分，这是我们的开发分支，虽然也很稳定但不建议您在正式产品中使用。
 
 如果你想编译最新稳定分支，你可以执行以下命令签出源码：
 
@@ -55,9 +55,9 @@ git checkout v{{< version >}}
 
 按照您的编译需求，以下 tags 可以使用：
 
-* `bindata`: 这个编译选项将会把运行Gitea所需的所有外部资源都打包到可执行文件中，这样部署将非常简单因为除了可执行程序将不再需要任何其他文件。
-* `sqlite sqlite_unlock_notify`: 这个编译选项将启用SQLite3数据库的支持，建议只在少数人使用时使用这个模式。
-* `pam`: 这个编译选项将会启用 PAM (Linux Pluggable Authentication Modules) 认证，如果你使用这一认证模式的话需要开启这个选项。
+- `bindata`: 这个编译选项将会把运行Gitea所需的所有外部资源都打包到可执行文件中，这样部署将非常简单因为除了可执行程序将不再需要任何其他文件。
+- `sqlite sqlite_unlock_notify`: 这个编译选项将启用SQLite3数据库的支持，建议只在少数人使用时使用这个模式。
+- `pam`: 这个编译选项将会启用 PAM (Linux Pluggable Authentication Modules) 认证，如果你使用这一认证模式的话需要开启这个选项。
 
 使用 bindata 可以打包资源文件到二进制可以使开发和测试更容易，你可以根据自己的需求决定是否打包资源文件。
 要包含资源文件，请使用 `bindata` tag：
diff --git a/docs/content/doc/installation/from-source.zh-tw.md b/docs/content/doc/installation/from-source.zh-tw.md
index 39c9878309..2b65d554ab 100644
--- a/docs/content/doc/installation/from-source.zh-tw.md
+++ b/docs/content/doc/installation/from-source.zh-tw.md
@@ -26,7 +26,7 @@ go get -d -u code.gitea.io/gitea
 cd $GOPATH/src/code.gitea.io/gitea
 ```
 
-現在該決定您要編譯或安裝的 Gitea 版本，您有很多可以選擇。如果您想編譯 `master` 版本，你可以直接跳到[編譯章節](#build)，這是我們開發分支，雖然很穩定，但是不建議用在正式環境。
+現在該決定您要編譯或安裝的 Gitea 版本，您有很多可以選擇。如果您想編譯 `master` 版本，你可以直接跳到[編譯章節](#編譯)，這是我們開發分支，雖然很穩定，但是不建議用在正式環境。
 
 假如您想要編譯最新穩定版本，可以執行底下命令切換到正確版本:
 
diff --git a/docs/content/doc/installation/on-kubernetes.zh-tw.md b/docs/content/doc/installation/on-kubernetes.zh-tw.md
index 5ea412aa00..345ff7ac2c 100644
--- a/docs/content/doc/installation/on-kubernetes.zh-tw.md
+++ b/docs/content/doc/installation/on-kubernetes.zh-tw.md
@@ -26,7 +26,7 @@ helm install gitea gitea-charts/gitea
 
 若您想自訂安裝（包括使用 kubernetes ingress），請前往完整的 [Gitea helm chart configuration details](https://gitea.com/gitea/helm-chart/)
 
-##運行狀況檢查終端節點
+## 運行狀況檢查終端節點
 
 Gitea 附帶了一個運行狀況檢查端點 `/api/healthz`，你可以像這樣在 kubernetes 中配置它:
 
diff --git a/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md b/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md
index 471377e9fc..9f65eaca9f 100644
--- a/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md
+++ b/docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md
@@ -27,12 +27,14 @@ Change the user, home directory, and other required startup values. Change the
 PORT or remove the -p flag if default port is used.
 
 Enable and start Gitea at boot:
+
 ```
 sudo systemctl enable gitea
 sudo systemctl start gitea
 ```
 
 If you have systemd version 220 or later, you can enable and immediately start Gitea at once by:
+
 ```
 sudo systemctl enable gitea --now
 ```
@@ -40,11 +42,13 @@ sudo systemctl enable gitea --now
 #### Using supervisor
 
 Install supervisor by running below command in terminal:
+
 ```
 sudo apt install supervisor
 ```
 
 Create a log dir for the supervisor logs:
+
 ```
 # assuming Gitea is installed in /home/git/gitea/
 mkdir /home/git/gitea/log/supervisor
@@ -58,12 +62,14 @@ Using your favorite editor, change the user (`git`) and home
 or remove the -p flag if default port is used.
 
 Lastly enable and start supervisor at boot:
+
 ```
 sudo systemctl enable supervisor
 sudo systemctl start supervisor
 ```
 
 If you have systemd version 220 or later, you can enable and immediately start supervisor by:
+
 ```
 sudo systemctl enable supervisor --now
 ```
diff --git a/docs/content/doc/installation/run-as-service-in-ubuntu.zh-cn.md b/docs/content/doc/installation/run-as-service-in-ubuntu.zh-cn.md
index 02cd032b67..c76350ecdc 100644
--- a/docs/content/doc/installation/run-as-service-in-ubuntu.zh-cn.md
+++ b/docs/content/doc/installation/run-as-service-in-ubuntu.zh-cn.md
@@ -18,6 +18,7 @@ menu:
 #### systemd 方式
 
 在 terminal 中执行以下命令：
+
 ```
 sudo vim /etc/systemd/system/gitea.service
 ```
@@ -27,26 +28,29 @@ sudo vim /etc/systemd/system/gitea.service
 修改 user，home 目录以及其他必须的初始化参数，如果使用自定义端口，则需修改 PORT 参数，反之如果使用默认端口则需删除 -p 标记。
 
 激活 gitea 并将它作为系统自启动服务：
+
 ```
 sudo systemctl enable gitea
 sudo systemctl start gitea
 ```
 
-
 #### 使用 supervisor
 
 在 terminal 中执行以下命令安装 supervisor：
+
 ```
 sudo apt install supervisor
 ```
 
 为 supervisor 配置日志路径：
+
 ```
 # assuming gitea is installed in /home/git/gitea/
 mkdir /home/git/gitea/log/supervisor
 ```
 
 在文件编辑器中打开 supervisor 的配置文件：
+
 ```
 sudo vim /etc/supervisor/supervisord.conf
 ```
@@ -57,6 +61,7 @@ sudo vim /etc/supervisor/supervisord.conf
 将 user(git) 和 home(/home/git) 设置为与上文部署中匹配的值。如果使用自定义端口，则需修改 PORT 参数，反之如果使用默认端口则需删除 -p 标记。
 
 最后激活 supervisor 并将它作为系统自启动服务：
+
 ```
 sudo systemctl enable supervisor
 sudo systemctl start supervisor
diff --git a/docs/content/doc/installation/with-docker-rootless.en-us.md b/docs/content/doc/installation/with-docker-rootless.en-us.md
index 634e08a72e..3cae65c2b2 100644
--- a/docs/content/doc/installation/with-docker-rootless.en-us.md
+++ b/docs/content/doc/installation/with-docker-rootless.en-us.md
@@ -247,6 +247,7 @@ files; for named volumes, this is done through another container or by direct ac
 :exclamation::exclamation: **Make sure you have volumed data to somewhere outside Docker container** :exclamation::exclamation:
 
 To upgrade your installation to the latest release:
+
 ```
 # Edit `docker-compose.yml` to update the version, if you have one specified
 # Pull new images
diff --git a/docs/content/doc/installation/with-docker.en-us.md b/docs/content/doc/installation/with-docker.en-us.md
index 940b38aa75..fb60b97118 100644
--- a/docs/content/doc/installation/with-docker.en-us.md
+++ b/docs/content/doc/installation/with-docker.en-us.md
@@ -255,7 +255,7 @@ favorite browser to finalize the installation. Visit http://server-ip:3000 and f
 installation wizard. If the database was started with the `docker-compose` setup as
 documented above, please note that `db` must be used as the database hostname.
 
-## Configure the user inside Gitea using environment variables 
+## Configure the user inside Gitea using environment variables
 
 - `USER`: **git**: The username of the user that runs Gitea within the container.
 - `USER_UID`: **1000**: The UID (Unix user ID) of the user that runs Gitea within the container. Match this to the UID of the owner of the `/data` volume if using host volumes (this is not necessary with named volumes).
@@ -394,9 +394,9 @@ In this option, the idea is that the host simply uses the `authorized_keys` that
 Here is a detailed explanation what is happening when a SSH request is made:
 
 1. The client adds their SSH public key to Gitea using the webpage.
-2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`. 
+2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`.
     - However, because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key has been added to the host `git` user's `authorized_keys` file too.
-3. This entry has the public key, but also has a `command=` option. 
+3. This entry has the public key, but also has a `command=` option.
     - This command matches the location of the Gitea binary on the container, but also the location of the shim on the host.
 4. The client then makes an SSH request to the host SSH server using the `git` user, e.g. `git clone git@domain:user/repo.git`.
 5. The client will attempt to authenticate with the server, passing one or more public keys in turn to the host.
@@ -441,7 +441,7 @@ we create a new shell for the git user. As an administrative user on the host ru
 Here is a detailed explanation what is happening when a SSH request is made:
 
 1. The client adds their SSH public key to Gitea using the webpage.
-2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`. 
+2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`.
     - However, because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key has been added to the host `git` user's `authorized_keys` file too.
 3. This entry has the public key, but also has a `command=` option.
     - This command matches the location of the Gitea binary on the container.
@@ -482,7 +482,7 @@ sudo usermod -s /home/git/docker-shell git
 Here is a detailed explanation what is happening when a SSH request is made:
 
 1. The client adds their SSH public key to Gitea using the webpage.
-2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`. 
+2. Gitea in the container will add an entry for this key to the `.ssh/authorized_keys` file of its running user, `git`.
     - However, because `/home/git/.ssh/` on the host is mounted as `/data/git/.ssh` this means that the key has been added to the host `git` user's `authorized_keys` file too.
 3. This entry has the public key, but also has a `command=` option.
     - This command matches the location of the Gitea binary on the container.
@@ -531,7 +531,7 @@ In this option, the idea is that the host SSH uses an `AuthorizedKeysCommand` in
 
 Now all attempts to login as the `git` user on the host will be forwarded to the docker - including the `SSH_ORIGINAL_COMMAND`. We now need to set-up SSH authentication on the host.
 
-We will do this by leveraging the [SSH AuthorizedKeysCommand](https://docs.gitea.io/en-us/command-line/#keys) to match the keys against those accepted by Gitea. 
+We will do this by leveraging the [SSH AuthorizedKeysCommand](https://docs.gitea.io/en-us/command-line/#keys) to match the keys against those accepted by Gitea.
 
 Add the following block to `/etc/ssh/sshd_config`, on the host: