2018-10-17 14:19:04 -04:00
|
|
|
|
---
|
|
|
|
|
|
date: "2018-06-01T19:00:00+02:00"
|
2023-05-23 06:14:57 -04:00
|
|
|
|
title: "合并请求"
|
2018-10-17 14:19:04 -04:00
|
|
|
|
slug: "pull-request"
|
2023-07-26 00:53:13 -04:00
|
|
|
|
sidebar_position: 13
|
2020-12-09 01:47:06 -05:00
|
|
|
|
toc: false
|
2018-10-17 14:19:04 -04:00
|
|
|
|
draft: false
|
Refactor docs (#23752)
This was intended to be a small followup for
https://github.com/go-gitea/gitea/pull/23712, but...here we are.
1. Our docs currently use `slug` as the entire URL, which makes
refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712).
Instead, this PR attempts to make future refactoring easier by using
slugs as an extension of the section. (Hugo terminology)
- What the above boils down to is this PR attempts to use directory
organization as URL management. e.g. `usage/comparison.en-us.md` ->
`en-us/usage/comparison/`, `usage/packages/overview.en-us.md` ->
`en-us/usage/packages/overview/`
- Technically we could even remove `slug`, as Hugo defaults to using
filename, however at least with this PR it means `slug` only needs to be
the name for the **current file** rather than an entire URL
2. This PR adds appropriate aliases (redirects) for pages, so anything
on the internet that links to our docs should hopefully not break.
3. A minor nit I've had for a while, renaming `seek-help` to `support`.
It's a minor thing, but `seek-help` has a strange connotation to it.
4. The commits are split such that you can review the first which is the
"actual" change, and the second is added redirects so that the first
doesn't break links elsewhere.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
2023-04-27 23:33:41 -04:00
|
|
|
|
aliases:
|
|
|
|
|
|
- /zh-cn/pull-request
|
2018-10-17 14:19:04 -04:00
|
|
|
|
menu:
|
|
|
|
|
|
sidebar:
|
|
|
|
|
|
parent: "usage"
|
|
|
|
|
|
name: "Pull Request"
|
2023-07-26 00:53:13 -04:00
|
|
|
|
sidebar_position: 13
|
2018-10-17 14:19:04 -04:00
|
|
|
|
identifier: "pull-request"
|
|
|
|
|
|
---
|
|
|
|
|
|
|
2023-05-23 06:14:57 -04:00
|
|
|
|
# 合并请求
|
2018-10-17 14:19:04 -04:00
|
|
|
|
|
2023-08-14 01:35:49 -04:00
|
|
|
|
合并请求(PR)是一种提出对仓库进行更改的方式。
|
|
|
|
|
|
它是一种将一个分支合并到另一个分支的请求，附带有对所做更改的描述。
|
|
|
|
|
|
合并请求通常用作贡献者对仓库贡献代码的方式，仓库的维护者可以通过对合并请求进行审查来决定是否接受这些更改。
|
2018-10-17 14:19:04 -04:00
|
|
|
|
|
2023-08-14 01:35:49 -04:00
|
|
|
|
## 创建合并请求
|
|
|
|
|
|
|
|
|
|
|
|
要创建合并请求，您需要遵循以下步骤：
|
|
|
|
|
|
|
|
|
|
|
|
1. **Fork 仓库** - 如果您没有直接对仓库进行更改的权限，您需要将仓库 fork 到您自己的账户中。
|
|
|
|
|
|
这将创建一个您可以对其进行更改的仓库副本。
|
|
|
|
|
|
|
|
|
|
|
|
2. **创建分支（可选）** - 在 fork 的仓库中创建一个新分支，该分支包含您要提出的更改。
|
|
|
|
|
|
给分支取一个描述性的名称，以指示更改的内容。
|
|
|
|
|
|
|
|
|
|
|
|
3. **进行更改** - 进行您想要的更改，提交并将其推送到 fork 的仓库中。
|
|
|
|
|
|
|
|
|
|
|
|
4. **创建合并请求** - 转到原始仓库并转到“合并请求”选项卡。单击“新建合并请求”按钮，并将您的新分支选择为源分支。
|
|
|
|
|
|
为您的合并请求输入描述性标题和描述，然后单击“创建合并请求”。
|
|
|
|
|
|
|
|
|
|
|
|
## 评审合并请求
|
|
|
|
|
|
|
|
|
|
|
|
创建合并请求后，将触发评审流程。仓库的维护者将收到合并请求的通知，并可以审查所做的更改。
|
|
|
|
|
|
他们可以留下评论、请求更改或批准更改。
|
|
|
|
|
|
|
|
|
|
|
|
如果维护者请求更改，您需要在分支中进行这些更改，并将更改推送到 fork 的仓库中。
|
|
|
|
|
|
合并请求将自动使用新更改进行更新。
|
|
|
|
|
|
|
|
|
|
|
|
如果维护者批准更改，他们可以将合并请求合并到仓库中。
|
|
|
|
|
|
|
|
|
|
|
|
## 关闭合并请求
|
|
|
|
|
|
|
|
|
|
|
|
如果您不接受该合并请求，您可以关闭它。
|
|
|
|
|
|
要关闭合并请求，请转到打开的合并请求并单击“关闭合并请求”按钮。这将关闭合并请求并且不会将其合并。
|
|
|
|
|
|
|
|
|
|
|
|
## 使用“Work In Progress”标记
|
|
|
|
|
|
|
|
|
|
|
|
在合并请求中使用“Work In Progress”标记可以防止合并请求被意外合并。
|
|
|
|
|
|
要将合并请求标记为“Work In Progress”，您必须在其标题中添加前缀`WIP:`或`[WIP]`（不区分大小写）。
|
|
|
|
|
|
标记前缀可以在您的`app.ini`文件中进行配置：
|
2018-10-17 14:19:04 -04:00
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
[repository.pull-request]
|
|
|
|
|
|
WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP]
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
列表的第一个值将用于 helpers 程序。
|
|
|
|
|
|
|
2023-05-23 06:14:57 -04:00
|
|
|
|
## 合并请求模板
|
2018-10-17 14:19:04 -04:00
|
|
|
|
|
2023-05-23 06:14:57 -04:00
|
|
|
|
有关合并请求模板的更多信息请您移步 : [工单与合并请求模板](issue-pull-request-templates)
|