自动链接的引用
当发布 Issue、Pull Request 或评论时，文本描述会被解析以搜索引用。这些引用将在 Issue 视图中显示为链接，并且在某些情况下会产生某些操作。
同样，提交信息在列出时也会被解析，并且当它们被推送到主分支时可以触发操作。
为了防止创建意外的引用，需要遵守某些规则才能识别它们。例如，它们不应该包含在代码文本中。它们也应该从周围的文本中合理地清除（例如，使用空格）。
用户、团队和组织提及
当找到 @username 形式的文本，并且 username 与现有用户的名称匹配时，就会创建一个提及引用。这将通过将文本更改为指向该用户个人资料的链接来显示，并且可能会根据用户是否具有访问内容的必要权限来为提及的用户创建通知。
示例
@John，你能看看这个吗？
这对团队和组织也适用
@Documenters，我们需要为此做计划。 @CoolCompanyInc，这个问题关系到我们所有人！
团队将在适当的时候收到邮件通知，但整个组织不会收到。
提交信息不会生成用户通知。
提交
提交可以使用它们的 SHA1 哈希或至少七个字符的部分来引用。它们将显示为指向相应提交的链接。
示例
这个 bug 是在 e59ff077 中引入的
Issue 和 Pull Request
对另一个 Issue 或 Pull Request 的引用可以使用简单符号 #1234 来创建，其中 1234 是同一仓库中 Issue 或 Pull Request 的编号。这些引用将显示为指向引用内容的链接。
创建这种类型的引用会产生一个通知，该通知会在引用的文档中创建，前提是引用的创建者具有对该文档的读取权限。
示例
这似乎与 #1234 有关
其他仓库中的 Issue 和 Pull Request 也可通过 owner/repository#1234 形式引用
这似乎与 mike/compiler#1234 有关
或者，也可以使用 !1234 符号。即使在 Gitea 中，Pull Request 是 Issue 的一种形式，#1234 形式也会始终链接到 Issue；如果链接的条目恰好是 Pull Request，Gitea 会按需重定向。使用 !1234 符号，将创建一个 Pull Request 链接，如果需要，它将被重定向到 Issue。但是，如果使用外部跟踪器，则这种区别可能很重要，因为对 Issue 和 Pull Request 的链接不可互换。
Pull Request 和提交信息中的可操作引用
有时，提交或 Pull Request 可能会修复或恢复特定 Issue 中记录的问题。Gitea 支持通过在引用之前加上特定的关键字来关闭和重新打开引用的 Issue。常见的关键字包括“关闭”、“修复”、“重新打开”等。此列表可以由网站管理员进行自定义。
示例
此 PR 关闭 #1234
如果可操作的引用被接受，这将在引用的 Issue 上创建一个通知，宣布该 Issue 在引用 PR 合并时将被关闭。
为了使可操作的引用被接受，必须满足以下至少一个条件
- 评论者在创建引用时具有关闭或重新打开 Issue 的权限。
- 引用在提交信息中。
- 引用作为 Pull Request 描述的一部分发布。
在最后一种情况下，只有在 Pull Request 的合并者具有执行此操作的权限时，Issue 才会被关闭或重新打开。
此外，只有 Pull Request 和提交信息可以创建操作，并且只有 Issue 可以通过这种方式关闭或重新打开。
默认的关键字为
- 关闭: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
- 重新打开: reopen, reopens, reopened
Pull Request 和提交信息中的时间跟踪
当提交或合并 Pull Request 导致自动关闭 Issue 时，可以通过提交信息添加解决此 Issue 的花费时间。
要指定解决 Issue 的花费时间，您需要在 Issue 编号之后以 @<number><time-unit> 格式指定时间。在一个提交信息中，您可以指定多个已修复的 Issue 和每个 Issue 的花费时间。
支持的时间单位 (<time-unit>)
m- 分钟h- 小时d- 天（等于 8 小时）w- 周（等于 5 天）mo- 月（等于 4 周）
指定时间的数字 (<number>) 也可以是十进制数字，例如 @1.5h 将导致一个半小时。可以组合使用多个时间单位，例如 @1h10m 表示 1 小时 10 分钟。
提交信息示例
Fixed #123 spent @1h, refs #102, fixes #124 @1.5h
这将导致 1 小时添加到 Issue #123，1 个半小时添加到 Issue #124。
外部跟踪器
Gitea 支持使用外部 Issue 跟踪器，并且可以在 Pull Request 中创建对外部托管的 Issue 的引用。但是，如果外部跟踪器使用数字来标识 Issue，它们将与 Gitea 中托管的 Pull Request 无法区分。为了解决这个问题，Gitea 允许使用 ! 标记来标识 Pull Request。例如
这是 Issue #1234，并链接到外部跟踪器。这是 Pull Request !1234，并链接到 Gitea 中的 Pull Request。
! 和 # 可以互换使用，用于 Issue 和 Pull Request，除了这种需要区分的情况。如果仓库使用外部跟踪器，则用于压缩合并的提交信息将默认使用 ! 作为引用。
Issue 和 Pull Request 引用摘要
此表说明了 Issue 和 Pull Request 的不同类型交叉引用。在示例中，User1/Repo1 指的是使用引用的仓库，而 UserZ/RepoZ 指的是另一个仓库。
| User1/Repo1 中的引用 | Repo1 Issue 为外部 | RepoZ Issue 为外部 | 应呈现 |
|---|---|---|---|
#1234 | 否 | - | 指向 User1/Repo1 中的 Issue/Pull 1234 的链接 |
!1234 | 否 | - | 指向 User1/Repo1 中的 Issue/Pull 1234 的链接 |
#1234 | 是 | - | 指向 User1/Repo1 的外部 Issue 1234 的链接 |
!1234 | 是 | - | 指向 User1/Repo1 的PR 1234 的链接 |
User1/Repo1#1234 | 否 | - | 指向 User1/Repo1 中的 Issue/Pull 1234 的链接 |
User1/Repo1!1234 | 否 | - | 指向 User1/Repo1 中的 Issue/Pull 1234 的链接 |
User1/Repo1#1234 | 是 | - | 指向 User1/Repo1 的外部 Issue 1234 的链接 |
User1/Repo1!1234 | 是 | - | 指向 User1/Repo1 的PR 1234 的链接 |
UserZ/RepoZ#1234 | - | 否 | 指向 UserZ/RepoZ 中的 Issue/Pull 1234 的链接 |
UserZ/RepoZ!1234 | - | 否 | 指向 UserZ/RepoZ 中的 Issue/Pull 1234 的链接 |
UserZ/RepoZ#1234 | - | 是 | 指向 UserZ/RepoZ 的外部 Issue 1234 的链接 |
UserZ/RepoZ!1234 | - | 是 | 指向 UserZ/RepoZ 的PR 1234 的链接 |
| 字母数字 Issue ID | - | - | - |
AAA-1234 | 是 | - | 指向 User1/Repo1 的外部 Issue AAA-1234 的链接 |
!1234 | 是 | - | 指向 User1/Repo1 的PR 1234 的链接 |
User1/Repo1!1234 | 是 | - | 指向 User1/Repo1 的PR 1234 的链接 |
| 不支持 | - | 是 | 指向 UserZ/RepoZ 的外部 Issue AAA-1234 的链接 |
UserZ/RepoZ!1234 | - | 是 | 指向 UserZ/RepoZ 的PR 1234 的链接 |
最后一部分用于具有外部 Issue 跟踪器的仓库，这些跟踪器使用字母数字格式。
-: 不适用。
注意：不同类型 Issue（外部与内部）的仓库之间的自动引用不受完全支持，并且可能会呈现无效的链接。