nprasad2077/docs
1
1
Fork 0
mirror of https://gitea.com/gitea/docs.git synced 2026-09-17 19:55:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add v1.26 documentation (#376)

Browse Source 
Co-authored-by: silverwind <[email protected]>
Reviewed-on: https://gitea.com/gitea/docs/pulls/376
Reviewed-by: silverwind <[email protected]>
This commit is contained in:
Lunny Xiao
2026-04-09 19:27:32 +00:00
co-authored by silverwind
parent b339770f3c
commit a7ab7af00f
329 changed files with 71328 additions and 254 deletions
Download Patch File Download Diff File Expand all files Collapse all files
i18n/zh-cn/docusaurus-plugin-content-docs/version-1.26/usage/issues-prs/_category_.json
+9
View File
@@ -0,0 +1,9 @@
{
"label": "工单 和 合并请求",
"position": 20,
"link": {
"type": "generated-index",
"slug": "/usage/issues-prs",
"description": "工单 和 合并请求 工作流，模板，和协作功能"
}
}
i18n/zh-cn/docusaurus-plugin-content-docs/version-1.26/usage/issues-prs/agit.md
+45
View File
@@ -0,0 +1,45 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "agit"
sidebar_position: 12
aliases:
- /zh-cn/agit-setup
---
# AGit
在 Gitea `1.13` 版本中，添加了对 [AGit](https://git-repo.info/zh/2020/03/agit-flow-and-git-repo/) 的支持。AGit 允许用户在没有仓库写入权限的情况下直接创建拉取请求，也不需要分叉仓库。这有助于减少重复仓库的数量，降低不必要的磁盘使用量。
:::note
服务器端需要 Git 版本 2.29 或更高版本才能正常运行。
:::
## 使用 AGit 创建 PR
AGit 允许在推送代码到远程仓库时创建 PR（合并请求）。
通过在推送时使用特定的 refspec（git 中已知的位置标识符），可以实现这一功能。
下面的示例说明了这一点：
```shell
git push origin HEAD:refs/for/main
```
该命令的结构如下：
- `HEAD`：目标分支
- `refs/<for|draft|for-review>/<branch>`：目标 PR 类型
- `for`：创建一个以 `<branch>` 为目标分支的普通 PR
- `draft`/`for-review`：目前被静默忽略
- `<branch>/<session>`：要打开 PR 的目标分支
- `-o <topic|title|description>`：PR 的选项
- `title`：PR 的标题
- `topic`：PR 应该打开的分支名称
- `description`：PR 的描述
- `force-push=true`: 是否强制更新目标分支
- 注意: 如果不传值，只用 `-o force-push` 也同样可以正常工作。
下面是另一个高级示例，用于创建一个以 `topic`、`title` 和 `description` 为参数的新 PR，目标分支是 `main`：
```shell
git push origin HEAD:refs/for/main -o topic="Topic of my PR" -o title="Title of the PR" -o description="# The PR Description\nThis can be **any** markdown content.\n- [x] Ok"
```
i18n/zh-cn/docusaurus-plugin-content-docs/version-1.26/usage/issues-prs/issue-pull-request-templates.md
+283
View File
@@ -0,0 +1,283 @@
---
date: "2022-09-07T16:00:00+08:00"
slug: "issue-pull-request-templates"
sidebar_position: 15
toc: true
aliases:
- /zh-cn/issue-pull-request-templates
---
# 从模板创建工单与合并请求
开发者可以利用问题模板创建工单与合并请求，其目的在于规范参与者的语言表达。
## 模板介绍
Gitea 支持两种格式的模板：Markdown 和 YAML。
### Markdown 模板
在 Gitea 中存在两种用途的 Markdown 模板：
- `ISSUE_TEMPLATE/bug-report.md` 用于规范工单的 Markdown 文本描述
- `PULL_REQUEST_TEMPLATE.md` 用于规范合并请求的 Markdown 文本描述
对于以上 Markdown 模板，我们推荐您将它们放置到项目目录 `.gitea` 进行收纳。
### YAML 模板
用 YAML 语法编写的模板相比 Markdown 可以实现更丰富的功能，利用表单实现诸如：问卷调查、字符校验。在 Gitea 中的 YAML 同样支持两种用途：
- `ISSUE_TEMPLATE/bug-report.yaml` 用于创建问卷调查形式的工单
- `PULL_REQUEST_TEMPLATE.yaml` 用于创建表单形式的合并请求
对于以上 YAML 模板，我们同样推荐您将它们放置到项目目录 `.gitea` 进行收纳。
##### 表单支持通过 URL 查询参数传值
当新建工单页面 URL 以 `?title=Issue+Title&body=Issue+Text` 为查询参数，表单将使用其中的参数（key-value）填充表单内容。
### Gitea 支持的模板文件路径
工单模板文件名:
- `ISSUE_TEMPLATE.md`
- `ISSUE_TEMPLATE.yaml`
- `ISSUE_TEMPLATE.yml`
- `issue_template.md`
- `issue_template.yaml`
- `issue_template.yml`
- `.gitea/ISSUE_TEMPLATE.md`
- `.gitea/ISSUE_TEMPLATE.yaml`
- `.gitea/ISSUE_TEMPLATE.yml`
- `.gitea/issue_template.md`
- `.gitea/issue_template.yaml`
- `.gitea/issue_template.yml`
- `.github/ISSUE_TEMPLATE.md`
- `.github/ISSUE_TEMPLATE.yaml`
- `.github/ISSUE_TEMPLATE.yml`
- `.github/issue_template.md`
- `.github/issue_template.yaml`
- `.github/issue_template.yml`
合并请求模板:
- `PULL_REQUEST_TEMPLATE.md`
- `PULL_REQUEST_TEMPLATE.yaml`
- `PULL_REQUEST_TEMPLATE.yml`
- `pull_request_template.md`
- `pull_request_template.yaml`
- `pull_request_template.yml`
- `.gitea/PULL_REQUEST_TEMPLATE.md`
- `.gitea/PULL_REQUEST_TEMPLATE.yaml`
- `.gitea/PULL_REQUEST_TEMPLATE.yml`
- `.gitea/pull_request_template.md`
- `.gitea/pull_request_template.yaml`
- `.gitea/pull_request_template.yml`
- `.github/PULL_REQUEST_TEMPLATE.md`
- `.github/PULL_REQUEST_TEMPLATE.yaml`
- `.github/PULL_REQUEST_TEMPLATE.yml`
- `.github/pull_request_template.md`
- `.github/pull_request_template.yaml`
- `.github/pull_request_template.yml`
#### 工单模板目录
由于工单存在多种类型，Gitea 支持将工单模板统一收纳到 `ISSUE_TEMPLATE` 目录。以下是 Gitea 支持的工单模板目录:
- `ISSUE_TEMPLATE`
- `issue_template`
- `.gitea/ISSUE_TEMPLATE`
- `.gitea/issue_template`
- `.github/ISSUE_TEMPLATE`
- `.github/issue_template`
- `.gitlab/ISSUE_TEMPLATE`
- `.gitlab/issue_template`
目录支持混合存放 Markdown (`.md`) 或 YAML (`.yaml`/`.yml`) 格式的工单模板。另外，合并请求模板不支持目录存放。
## Markdown 模板语法
```md
---
name: "Template Name"
about: "This template is for testing!"
title: "[TEST] "
ref: "main"
labels:
- bug
- "help needed"
---
This is the template!
```
上面的示例表示用户从列表中选择一个工单模板时，列表会展示模板名称 `Template Name` 和模板描述 `This template is for testing!`。 同时，标题会预先填充为 `[TEST]`，而正文将预先填充 `This is the template!`。该 Issue 会被指派给 `user1`。 最后，Issue 还会被分配两个标签，`bug` 和 `help needed`，并且将问题指向 `main` 分支。
## YAML 模板语法
YAML 模板格式如下，相比 Markdown 模板提供了更多实用性的功能。
```yaml
name: 表单名称
about: 表单描述
title: 默认标题
body: 主体内容
type: 定义表单元素类型
id: 定义表单标号
attributes: 扩展的属性
validations: 内容校验
```
下例 YAML 配置文件完整定义了一个用于提交 bug 的问卷调查。
```yaml
name: Bug Report
about: File a bug report
title: "[Bug]: "
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this bug report!
- type: input
id: contact
attributes:
label: Contact Details
description: How can we get in touch with you if we need more info?
placeholder: ex. [email protected]
validations:
required: false
- type: textarea
id: what-happened
attributes:
label: What happened?
description: Also tell us, what did you expect to happen?
placeholder: Tell us what you see!
value: "A bug happened!"
validations:
required: true
- type: dropdown
id: version
attributes:
label: Version
description: What version of our software are you running?
options:
- 1.0.2 (Default)
- 1.0.3 (Edge)
validations:
required: true
- type: dropdown
id: browsers
attributes:
label: What browsers are you seeing the problem on?
multiple: true
options:
- Firefox
- Chrome
- Safari
- Microsoft Edge
- type: textarea
id: logs
attributes:
label: Relevant log output
description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
render: shell
- type: checkboxes
id: terms
attributes:
label: Code of Conduct
description: By submitting this issue, you agree to follow our [Code of Conduct](https://example.com)
options:
- label: I agree to follow this project's Code of Conduct
required: true
```
### Markdown 段落
您可以在 YAML 模板中使用 `markdown` 元素为开发者提供额外的上下文支撑，这部分内容会作为创建工单的提示但不会作为工单内容提交。
`attributes` 子项提供了以下扩展能力：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ------- | ------------------------------ | ---- | ------ | ------ | ------ |
| `value` | 渲染的文本。支持 Markdown 格式 | 必选 | 字符串 | - | - |
### Textarea 多行文本输入框
您可以使用 `textarea` 元素在表单中添加多行文本输入框。 除了输入文本，开发者还可以在 `textarea` 区域附加文件。
`attributes` 子项提供了以下扩展能力：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ------------- | ----------------------------------------------------------------------------------------------------- | ---- | ------ | -------- | ------------------ |
| `label` | 预期用户输入的简短描述，也以表单形式显示。 | 必选 | 字符串 | - | - |
| `description` | 提供上下文或指导的文本区域的描述，以表单形式显示。 | 可选 | 字符串 | 空字符串 | - |
| `placeholder` | 半透明的占位符，在文本区域空白时呈现 | 可选 | 字符串 | 空字符串 | - |
| `value` | 在文本区域中预填充的文本。 | 可选 | 字符串 | - | - |
| `render` | 如果提供了值，提交的文本将格式化为代码块。 提供此键时，文本区域将不会扩展到文件附件或 Markdown 编辑。 | 可选 | 字符串 | - | Gitea 支持的语言。 |
`validations` 子项提供以下文本校验参数：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ---------- | ---------------------------- | ---- | ------ | ------ | ------ |
| `required` | 防止在元素完成之前提交表单。 | 可选 | 布尔型 | false | - |
### Input 单行输入框
您可以使用 `input` 元素添加单行文本字段到表单。
`attributes` 子项提供了以下扩展能力：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ------------- | ---------------------------------------------- | ---- | ------ | -------- | ------ |
| `label` | 预期用户输入的简短描述，也以表单形式显示。 | 必选 | 字符串 | - | - |
| `description` | 提供上下文或指导的字段的描述，以表单形式显示。 | 可选 | 字符串 | 空字符串 | - |
| `placeholder` | 半透明的占位符，在字段空白时呈现。 | 可选 | 字符串 | 空字符串 | - |
| `value` | 字段中预填的文本。 | 可选 | 字符串 | - | - |
`validations` 子项提供以下文本校验参数：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ----------- | -------------------------------- | ---- | ------ | ------ | -------------------------------------------------------------- |
| `required` | 防止在未填内容时提交表单。 | 可选 | 布尔型 | false | - |
| `is_number` | 防止在未填数字时提交表单。 | 可选 | 布尔型 | false | - |
| `regex` | 直到满足了与正则表达式匹配的值。 | 可选 | 字符串 | - | [正则表达式](https://en.wikipedia.org/wiki/Regular_expression) |
### Dropdown 下拉菜单
您可以使用 `dropdown` 元素在表单中添加下拉菜单。
`attributes` 子项提供了以下扩展能力：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ------------- | --------------------------------------------------------- | ---- | ---------- | -------- | ------ |
| `label` | 预期用户输入的简短描述，以表单形式显示。 | 必选 | 字符串 | - | - |
| `description` | 提供上下文或指导的下拉列表的描述，以表单形式显示。 | 可选 | 字符串 | 空字符串 | - |
| `multiple` | 确定用户是否可以选择多个选项。 | 可选 | 布尔型 | false | - |
| `options` | 用户可以选择的选项列表。 不能为空，所有选择必须是不同的。 | 必选 | 字符串数组 | - | - |
`validations` 子项提供以下文本校验参数：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ---------- | ---------------------------- | ---- | ------ | ------ | ------ |
| `required` | 防止在元素完成之前提交表单。 | 可选 | 布尔型 | false | - |
### Checkboxes 复选框
您可以使用 `checkboxes` 元素添加一组复选框到表单。
`attributes` 子项提供了以下扩展能力：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ------------- | ----------------------------------------------------- | ---- | ------ | -------- | ------ |
| `label` | 预期用户输入的简短描述，以表单形式显示。 | 必选 | 字符串 | - | - |
| `description` | 复选框集的描述，以表单形式显示。 支持 Markdown 格式。 | 可选 | 字符串 | 空字符串 | - |
| `options` | 用户可以选择的复选框列表。 有关语法，请参阅下文。 | 必选 | 数组 | - | - |
对于 `options`，您可以设置以下参数：
| 键 | 描述 | 必选 | 类型 | 默认值 | 有效值 |
| ---------- | --------------------------------------------------------------------------------- | ---- | ------ | ------ | ------ |
| `label` | 选项的标识符，显示在表单中。 支持 Markdown 用于粗体或斜体文本格式化和超文本链接。 | 必选 | 字符串 | - | - |
| `required` | 防止在元素完成之前提交表单。 | 可选 | 布尔型 | false | - |
i18n/zh-cn/docusaurus-plugin-content-docs/version-1.26/usage/issues-prs/labels.md
+33
View File
@@ -0,0 +1,33 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "labels"
sidebar_position: 13
aliases:
- /zh-cn/labels
---
# 标签
您可以使用标签对工单和合并请求进行分类，并提高对它们的概览。
## 创建标签
对于仓库，可以在 `工单（Issues）` 中点击 `标签（Labels）` 来创建标签。
对于组织，您可以定义组织级别的标签，这些标签与所有组织仓库共享，包括已存在的仓库和新创建的仓库。可以在组织的 `设置（Settings）` 中创建组织级别的标签。
标签具有必填的名称和颜色，可选的描述，以及必须是独占的或非独占的（见下面的“作用域标签”）。
当您创建一个仓库时，可以通过使用 `工单标签（Issue Labels）` 选项来选择标签集。该选项列出了一些在您的实例上 [全局配置的可用标签集](../administration/customizing-gitea.md#labels)。在创建仓库时，这些标签也将被创建。
## 作用域标签
作用域标签用于确保将至多一个具有相同作用域的标签分配给工单或合并请求。例如，如果标签 `kind/bug` 和 `kind/enhancement` 的独占选项被设置，那么工单只能被分类为 bug 或 enhancement 中的一个。
作用域标签的名称必须包含 `/`（不能在名称的任一端）。标签的作用域是基于最后一个 `/` 决定的，因此例如标签 `scope/subscope/item` 的作用域是 `scope/subscope`。
## 按标签筛选
工单和合并请求列表可以按标签进行筛选。选择多个标签将显示具有所有选定标签的工单和合并请求。
通过按住 alt 键并单击标签，可以将具有所选标签的工单和合并请求从列表中排除。
i18n/zh-cn/docusaurus-plugin-content-docs/version-1.26/usage/issues-prs/linked-references.md
+143
View File
@@ -0,0 +1,143 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "automatically-linked-references"
sidebar_position: 15
aliases:
- /zh-cn/automatically-linked-references
---
# 自动链接引用
当发布工单、合并请求或评论时，文本描述会被解析以查找引用。这些引用将显示为工单视图中的链接，并且在某些情况下会触发特定的“操作”。
类似地，当列出提交消息时，它们也会被解析，并且当它们被推送到主分支时可以触发“操作”。
为了防止意外创建引用，对于引用的识别有一定的规则。例如，它们不应该包含在代码文本内部。它们还应该在周围的文本中合理清晰（例如，使用空格）。
## 用户、团队和组织提及
当找到形式为 `@username` 的文本，并且 `username` 与现有用户的名称匹配时，将创建一个“提及”引用。这将通过将文本更改为指向该用户个人资料的链接来显示，并根据被提及的用户是否具有访问内容所需的权限来可能创建通知。
示例：
> [@John](#)，你能看一下这个吗？
对于团队和组织也是有效的：
> [@Documenters](#)，我们需要为此进行规划。
> [@CoolCompanyInc](#)，这个问题关系到我们所有人！
团队将在适当时收到邮件通知，但整个组织不会收到通知。
提交消息不会产生用户通知。
## 提交
可以使用提交的 SHA1 哈希或至少七个字符的一部分来引用提交。它们将显示为指向相应提交的链接。
示例：
> 这个错误是在 [e59ff077](#) 中引入的
## 工单和合并请求
可以使用简单的符号 `#1234` 来创建对另一个工单或合并请求的引用，其中 _1234_ 是同一仓库中一个工单或合并请求的编号。这些引用将显示为指向被引用内容的链接。
创建此类型引用的效果是，在被引用的文档中创建一个“通知”，前提是引用的创建者对其具有读取权限。
示例：
> 这似乎与 [#1234](#) 相关
还可以使用形式 `owner/repository#1234` 来引用其他仓库中的工单和合并请求：
> 这似乎与 [mike/compiler#1234](#) 相关
或者也可以使用 `!1234` 符号。虽然在 Gitea 中合并请求是工单的一种形式，但 `#1234` 形式总是链接到工单；如果链接的条目恰好是一个合并请求，Gitea 会适当地进行重定向。而使用 `!1234` 符号，则会创建一个合并请求链接，根据需要会被重定向到工单。然而，如果使用外部跟踪器，这个区别可能很重要，因为工单和合并请求的链接是不能互换的。
## 可操作的引用在合并请求和提交消息中
有时，一个提交或合并请求可能会修复或重新出现在某个特定工单中。Gitea 支持在引用之前加上特定的“关键字”来关闭和重新打开被引用的工单。常见的关键字包括“closes”、“fixes”、“reopens”等。这个列表可以由站点管理员进行 [自定义](../administration/config-cheat-sheet.md)。
示例：
> 这个合并请求 _closes_ [#1234](#)
如果可操作的引用被接受，这将在被引用的工单上创建一个通知，宣布当引用的合并请求被合并时该工单将被关闭。
为了接受可操作的引用，必须满足以下至少一项条件之一：
- 评论者在创建引用时具有关闭或重新打开工单的权限。
- 引用位于提交消息中。
- 引用作为合并请求描述的一部分发布。
在最后一种情况下，只有当合并合并请求的人具有相应权限时，工单才会被关闭或重新打开。
此外，只有合并请求和提交消息可以创建一个操作，只有工单可以通过这种方式被关闭或重新打开。
默认的关键字如下：
- **关闭工单**: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
- **重新打开工单**: reopen, reopens, reopened
## 合并请求和提交消息中的时间跟踪
当提交或合并合并请求导致自动关闭工单时，还可以通过提交消息添加解决此工单所花费的时间。
要指定解决工单所花费的时间，需要在工单编号后面以 `@<number><time-unit>` 的格式指定时间。在一个提交消息中，可以指定多个已解决的工单，并为每个工单指定花费的时间。
支持的时间单位（`<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
这将导致工单 #123 增加 1 小时，工单 #124 增加 1 小时半。
## 外部跟踪器
Gitea 支持使用外部工单跟踪器，并可以在合并请求中创建对外部托管的工单的引用。但是，如果外部跟踪器使用数字来标识工单，那么它们将与 Gitea 中托管的合并请求无法区分。为了解决这个问题，Gitea 允许使用 `!` 标记来标识合并请求。例如：
> 这是工单 [#1234](#)，并链接到外部跟踪器。
> 这是合并请求 [!1234](#)，并链接到 Gitea 中的合并请求。
在工单和合并请求中，`!` 和 `#` 可以互换使用，除非需要进行区分。如果仓库使用外部跟踪器，默认情况下，合并提交消息将使用 `!` 作为引用。
## 工单和合并请求引用摘要
下表说明了工单和合并请求的不同类型的交叉引用。在示例中，`User1/Repo1` 指的是使用引用的仓库，而 `UserZ/RepoZ` 表示另一个仓库。
| 在 User1/Repo1 中的引用 | Repo1 的工单是外部的 | RepoZ 的工单是外部的 | 渲染效果 |
| ----------------------- | :------------------: | :------------------: | --------------------------------------------- |
| `#1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
| `!1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
| `#1234` | 是 | - | 链接到 `User1/Repo1` 的 _外部工单_ 1234 |
| `!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
| `User1/Repo1#1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
| `User1/Repo1!1234` | 否 | - | 链接到 `User1/Repo1` 中的工单/合并请求 1234 |
| `User1/Repo1#1234` | 是 | - | 链接到 `User1/Repo1` 的 _外部工单_ 1234 |
| `User1/Repo1!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
| `UserZ/RepoZ#1234` | - | 否 | 链接到 `UserZ/RepoZ` 中的工单/合并请求 1234 |
| `UserZ/RepoZ!1234` | - | 否 | 链接到 `UserZ/RepoZ` 中的工单/合并请求 1234 |
| `UserZ/RepoZ#1234` | - | 是 | 链接到 `UserZ/RepoZ` 的 _外部工单_ 1234 |
| `UserZ/RepoZ!1234` | - | 是 | 链接到 `UserZ/RepoZ` 的 _PR_ 1234 |
| **字母数字工单编号:** | - | - | - |
| `AAA-1234` | 是 | - | 链接到 `User1/Repo1` 的 _外部工单_ `AAA-1234` |
| `!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
| `User1/Repo1!1234` | 是 | - | 链接到 `User1/Repo1` 的 _PR_ 1234 |
| _不支持_ | - | 是 | 链接到 `UserZ/RepoZ` 的 _外部工单_ `AAA-1234` |
| `UserZ/RepoZ!1234` | - | 是 | 链接到 `UserZ/RepoZ` 中的 _PR_ 1234 |
_最后一部分适用于使用字母数字格式的外部工单跟踪器的仓库。_
_**-**: 不适用_
注意：不完全支持具有不同类型工单（外部 vs. 内部）的仓库之间的自动引用，可能会导致无效链接。
i18n/zh-cn/docusaurus-plugin-content-docs/version-1.26/usage/issues-prs/merge-message-templates.md
+47
View File
@@ -0,0 +1,47 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "merge-message-templates"
sidebar_position: 15
aliases:
- /zh-cn/merge-message-templates
---
# 合并消息模板
## 文件名
PR 默认合并消息模板可能的文件名：
- `.gitea/default_merge_message/MERGE_TEMPLATE.md`
- `.gitea/default_merge_message/REBASE_TEMPLATE.md`
- `.gitea/default_merge_message/REBASE-MERGE_TEMPLATE.md`
- `.gitea/default_merge_message/SQUASH_TEMPLATE.md`
- `.gitea/default_merge_message/MANUALLY-MERGED_TEMPLATE.md`
- `.gitea/default_merge_message/REBASE-UPDATE-ONLY_TEMPLATE.md`
## 变量
您可以在这些模板中使用以下以 `${}` 包围的变量，这些变量遵循 [os.Expand](https://pkg.go.dev/os#Expand) 语法：
- BaseRepoOwnerName：此合并请求的基础仓库所有者名称
- BaseRepoName：此合并请求的基础仓库名称
- BaseBranch：此合并请求的基础仓库目标分支名称
- HeadRepoOwnerName：此合并请求的源仓库所有者名称
- HeadRepoName：此合并请求的源仓库名称
- HeadBranch：此合并请求的源仓库分支名称
- PullRequestTitle：合并请求的标题
- PullRequestDescription：合并请求的描述
- PullRequestPosterName：合并请求的提交者名称
- PullRequestIndex：合并请求的索引号
- PullRequestReference：合并请求的引用字符与索引号。例如，#1、!2
- ClosingIssues：返回一个包含将由此合并请求关闭的所有工单的字符串。例如 `close #1, close #2`
- ReviewedOn: 该提交所属的合并请求。例如： `Reviewed-on: https://gitea.com/foo/bar/pulls/1`
- ReviewedBy: 谁同意的此合并请求。例如： `Reviewed-by: Jane Doe <[email protected]>`
## 变基（Rebase）
在没有合并提交的情况下进行变基时，`REBASE_TEMPLATE.md` 修改最后一次提交的消息。此模板还提供以下附加变量：
- CommitTitle：提交的标题
- CommitBody：提交的正文文本
i18n/zh-cn/docusaurus-plugin-content-docs/version-1.26/usage/issues-prs/pull-request.md
+60
View File
@@ -0,0 +1,60 @@
---
date: "2018-06-01T19:00:00+02:00"
slug: "pull-request"
sidebar_position: 13
aliases:
- /zh-cn/pull-request
---
# 合并请求
合并请求(PR)是一种提出对仓库进行更改的方式。
它是一种将一个分支合并到另一个分支的请求，附带有对所做更改的描述。
合并请求通常用作贡献者对仓库贡献代码的方式，仓库的维护者可以通过对合并请求进行审查来决定是否接受这些更改。
## 创建合并请求
要创建合并请求，您需要遵循以下步骤：
1. **Fork 仓库** - 如果您没有直接对仓库进行更改的权限，您需要将仓库 fork 到您自己的账户中。
这将创建一个您可以对其进行更改的仓库副本。
2. **创建分支（可选）** - 在 fork 的仓库中创建一个新分支，该分支包含您要提出的更改。
给分支取一个描述性的名称，以指示更改的内容。
3. **进行更改** - 进行您想要的更改，提交并将其推送到 fork 的仓库中。
4. **创建合并请求** - 转到原始仓库并转到“合并请求”选项卡。单击“新建合并请求”按钮，并将您的新分支选择为源分支。
为您的合并请求输入描述性标题和描述，然后单击“创建合并请求”。
## 评审合并请求
创建合并请求后，将触发评审流程。仓库的维护者将收到合并请求的通知，并可以审查所做的更改。
他们可以留下评论、请求更改或批准更改。
如果维护者请求更改，您需要在分支中进行这些更改，并将更改推送到 fork 的仓库中。
合并请求将自动使用新更改进行更新。
如果维护者批准更改，他们可以将合并请求合并到仓库中。
## 关闭合并请求
如果您不接受该合并请求，您可以关闭它。
要关闭合并请求，请转到打开的合并请求并单击“关闭合并请求”按钮。这将关闭合并请求并且不会将其合并。
## 使用“Work In Progress”标记
在合并请求中使用“Work In Progress”标记可以防止合并请求被意外合并。
要将合并请求标记为“Work In Progress”，您必须在其标题中添加前缀`WIP:`或`[WIP]`（不区分大小写）。
标记前缀可以在您的`app.ini`文件中进行配置：
```
[repository.pull-request]
WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP]
```
列表的第一个值将用于 helpers 程序。
## 合并请求模板
有关合并请求模板的更多信息请您移步 : [工单与合并请求模板](usage/issue-pull-request-templates.md)