自动链接引用
当发布工单、合并请求或评论时,文本描述会被解析以查找引用。这些引用将显示为工单视图中的链接,并且在某些情况下会触发特定的“操作”。
类似地,当列出提交消息时,它们也会被解析,并且当它们被推送到主分支时可以触发“操作”。
为了防止意外创建引用,对于引用的识别有一定的规则。例如,它们不应该包含在代码文本内部。它们还应该在周围的文本中合理清晰(例如,使用空格)。
用户、团队和组织提及
当找到形式为 @username
的文本,并且 username
与现有用户的名称匹配时,将创建一个“提及”引用。这将通过将文本更改为指向该用户个人资料的链接来显示,并根据被提及的用户是否具有访问内容所需的权限来可能创建通知。
示例:
@John,你能看一下这个吗?
对于团队和组织也是有效的:
@Documenters,我们需要为此进行规划。 @CoolCompanyInc,这个问题关系到我们所有人!
团队将在适当时收到邮件通知,但整个组织不会收到通知。
提交消息不会产生用户通知。
提交
可以使用提交的 SHA1 哈希或至少七个字符的一部分来引用提交。它们将显示为指向相应提交的链接。
示例:
这个错误是在 e59ff077 中引入的
工单和合并请求
可以使用简单的符号 #1234
来创建对另一个工单或合并请求的引用,其中 1234 是同一仓库中一个工单或合并请求的编号。这些引用将显示为指向被引用内容的链接。
创建此类型引用的效果是,在被引用的文档中创建一个“通知”,前提是引用的创建者对其具有读取权限。
示例:
这似乎与 #1234 相关
还可以使用形式 owner/repository#1234
来引用其他仓库中的工单和合并请求:
这似乎与 mike/compiler#1234 相关
或者也可以使用 !1234
符号。虽然在 Gitea 中合并请求是工单的一种形式,但 #1234
形式总是链接到工单;如果链接的条目恰好是一个合并请求,Gitea 会适当地进行重定向。而使用 !1234
符号,则会创建一个合并请求链接,根据需要会被重定向到工单。然而,如果使用外部跟踪器,这个区别可能很重要,因为工单和合并请求的链接是不能互换的。