Pull request 帮助我的团队避免了缺陷、在实现决策上达成一致，并从彼此的代码中学习。在本指南中，我将向您展示如何在基于 Git 的平台上使用 pull request，安全地评审您的代码。
如果您刚开始使用 Git，建议先学习我们的 Introduction to Git 和 Introduction to GitHub Concepts 课程，了解版本控制以及 Git 与 GitHub 的区别。此外，我觉得可下载的 Git 速查表 很实用，作为参考时包含了最常见的 Git 术语与命令。
什么是 Pull Request？
Pull request 本质上是一种对代码提出变更建议的方式。设想您在开发某个功能或在一个独立分支上工作，pull request 能让您请求将这些更改合并进主代码库。通常，这会在他人有机会评审之后进行。Pull request 是协作式开发的核心，尤其在团队协作中。
值得一提的是，在 GitLab 上，这一流程称为“Merge Request”。
Pull Request 如何工作？
以下步骤概述了 pull request 的基本工作流：
- 在功能分支中对脚本（代码）进行更改。
- 在本地代码库中提交这些更改。
- 将分支推送到远程代码库，例如 GitHub。
- 打开 pull request，建议将更改合并到主分支。
- 为所提议的更改请求评审。
- 合并或关闭 pull request，具体取决于评审结果。
该工作流让每位开发者都有机会在代码上线前评审代码并识别潜在问题。
pull request 过程中的关键角色包括：
- 贡献者：进行更改并打开 pull request 的开发者。
- 评审者：评审所提议代码更改的开发者，以提出改进建议并确保代码质量。
- 维护者：拥有项目并有权批准或拒绝 pull request 的项目管理者。
我建议学习我们的 Intermediate Git 课程，了解如何在 Git 中创建分支，以及如何与团队成员进行远程协作。
创建 Pull Request（含示例）
假设您发现项目 README 文件的开头一句有错误。您希望在不影响主分支的情况下修复它。请按以下步骤操作：
步骤 1：创建新分支
进入项目文件夹，打开终端运行下面的命令。这行命令会创建一个新分支。
git checkout -b fix-readme-typo技术支持
步骤 2：进行修改
打开代码编辑器中的 README.md 文件，修正错别字，并保存文件。
步骤 3：提交变更
使用以下命令暂存并提交更改：
git add README.md
git commit -m "Fix typo in README"技术支持
步骤 4：将分支推送到 GitHub
将该分支上传到代码库。
git push origin fix-readme-typo技术支持
步骤 5：打开 GitHub 并创建 pull request
现在打开您的 GitHub 账户，按以下步骤进行：
步骤 6：请求评审并提交
如果您的项目涉及其他开发者，您可以请求评审者，或在项目使用标签时添加标签。然后点击Create pull request。
查看我们的项目 Performing a Code Review，了解如何在代码上线前进行评审与修改。
Pull Request 最佳实践
以下最佳实践可帮助您在创建 pull request 时确保高质量开发：
- 保持 pull request 精炼、简单： 每个功能建议从一个 pull request 开始。这有助于评审者跟踪和测试您的改动，并尽量减少引入缺陷的可能性。
- 撰写清晰的提交信息与描述： 提供具有描述性的提交信息来解释修改内容。这些背景可帮助评审者无需通读代码就理解您的意图。
- 利用草稿 pull request 获取早期反馈： 工作尚未完成但需要反馈时，创建草稿 pull request。它表明代码仍在进行中，便于讨论而不必立即合并。
- 充分测试并分享上下文： 始终仔细检查您的更改，确保一切按预期工作。
不同 Git 工作流中的 Pull Request
下面快速概述不同团队设置如何使用 pull request。
-
功能分支（Feature branching）：在小团队和私有代码库中很常见。该工作流为每个功能创建一个新分支。
-
Fork 工作流：用于开源项目。此工作流要求贡献者将主仓库 fork（复制）到自己的账户中，在 fork 中进行更改，然后向原仓库发起 pull request。
-
GitFlow：一种结构化工作流，使用 main、develop、release 和 hotfix 等长期分支。常见于发布周期更复杂的大型团队。
Pull Request 礼仪
礼仪同样重要，pull request 也有其特定的行为准则：
- 保持尊重并具体： 关注代码本身，而非个体。
- 让 pull request 聚焦：避免在一个 pull request 中混杂不相关的更改。忽视这一点只会让评审与反馈更复杂。
- 认真回应反馈： 认可写得好的代码与改进建议。
- 不要让 pull request 长期搁置：尽可能快速评审并处理 pull request，避免延误更新。
- 主动提问： 若有不清楚之处，寻求澄清而非主观臆断，以避免误解。
- 提出改进建议： 在合适的情况下，给出可执行的建议或替代方案，而不仅仅是指出问题。
进阶 Pull Request 工作流与最佳实践
如果您是有经验的开发者，想让协作更顺畅、提升代码质量并扩展 pull request 流程，以下实用技巧可帮助您优化工作流。
更聪明的工作流
不同的 Git 工作流对 pull request 的处理各有不同。正如前文所述，功能分支因其简单性非常适合小团队，但随着团队壮大，维护难度可能上升。
Fork 工作流推荐用于开源项目，但在同步与评审外部贡献时可能引入额外开销。类似地，GitFlow 适用于节奏较快的开发，不过其复杂性也可能放慢流程。
自动化与集成
现代 pull request 配有 CI/CD 检查，通过集成持续集成工具在每个 PR 上运行测试、代码规范检查并部署预览，从而自动化质量门槛，确保只有符合既定标准的代码才会被合并。
GitHub Actions 与 GitLab Pipelines 等平台也支持自动化。这些流程包括运行单元测试、构建与部署预览环境，减少手工操作并及早发现问题。
优化评审
始终让 pull request 小而聚焦，以便快速且全面地评审。使用包含“变更内容”“如何测试”等清晰字段的模板，能帮助贡献者提供简明且相关的信息，使评审更高效。
此外，请注意以提问代替命令式表达有助于建立建设性对话与学习。若您为评审设定周转时间，将有助于保持流程可预期并避免延误。
度量与现代工具
我也建议跟踪 PR 规模、评审用时与合并率，以识别瓶颈并提升工作流效率。为便于评审与合并，可尝试使用“叠放式（stacked）pull request”，将大型功能拆分为多个彼此关联、逐步构建的 PR。
此外，您可以在使用 pull request 时集成如 GitHub Copilot 或 CodeWhisperer 等 AI 工具，它们可帮助您尽早突出潜在问题并给出修正建议。
Pull Request 与 Merge Request 的区别
在 GitHub 与 GitLab 中，Pull Request（PR）与 Merge Request（MR）常被交替使用。尽管用途相同，但各平台的处理方式有所不同。
下表比较了 PR 与 MR，以突出这些差异。
|
方面
|
Pull Request（GitHub）
|
Merge Request（GitLab）
|
|
术语
|
请求拉取更改
|
请求合并更改
|
|
主要用途
|
提出、评审并合并代码更改
|
提出、评审并合并代码更改
|
|
典型用户
|
开源开发者、中小型团队
|
DevOps 密集型团队、企业与私有仓库
|
|
CI/CD 集成
|
GitHub Actions（可选，需配置）
|
默认内置 CI/CD
|
|
草稿支持
|
原生支持 Draft PR
|
通过“Draft”标签或 WIP 前缀支持
|
|
合并审批
|
基础的评审者与审批设置
|
高级规则：多审批人、审批流水线
|
|
合并策略
|
合并提交、压缩合并或变基
|
类似选项，并可配置合并方式限制
|
|
工作流理念
|
以开发者为中心，灵活
|
聚焦 DevOps，开发与运维深度集成
|
结语
对于任何严肃的项目，pull request 都是必须掌握的。正如您所见（也希望您已认可），它让团队能够协作地评审、讨论并改进代码。
持续提升您的开发者技能。查看我们的 Git Fundamentals 与 GitHub Foundations 技能路径，全面精通 Git 相关内容。
%22%3E%3Cpath%20d%3D%22m-369%200h408v79h-408z%22%20fill%3D%22%237933ff%22%2F%3E%3Cpath%20d%3D%22m-148%200h306v45h-306z%22%20fill%3D%22%23974dff%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
%22%2F%3E%3C%2FclipPath%3E%3Cg%20clip-path%3D%22url(%23a)%22%3E%3Cpath%20d%3D%22m76%200h484v36h-484z%22%20fill%3D%22%23974dff%22%2F%3E%3Cpath%20d%3D%22m0%200h384v24h-384z%22%20fill%3D%22%2306bdfc%22%20transform%3D%22matrix(1%200%200%20-1%200%2060)%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
Pull request 帮助我的团队避免了缺陷、在实现决策上达成一致，并从彼此的代码中学习。在本指南中，我将向您展示如何在基于 Git 的平台上使用 pull request，安全地评审您的代码。
如果您刚开始使用 Git，建议先学习我们的 Introduction to Git 和 Introduction to GitHub Concepts 课程，了解版本控制以及 Git 与 GitHub 的区别。此外，我觉得可下载的 Git 速查表 很实用，作为参考时包含了最常见的 Git 术语与命令。
什么是 Pull Request？
Pull request 本质上是一种对代码提出变更建议的方式。设想您在开发某个功能或在一个独立分支上工作，pull request 能让您请求将这些更改合并进主代码库。通常，这会在他人有机会评审之后进行。Pull request 是协作式开发的核心，尤其在团队协作中。
值得一提的是，在 GitLab 上，这一流程称为“Merge Request”。
Pull Request 如何工作？
以下步骤概述了 pull request 的基本工作流：
该工作流让每位开发者都有机会在代码上线前评审代码并识别潜在问题。
pull request 过程中的关键角色包括：
我建议学习我们的 Intermediate Git 课程，了解如何在 Git 中创建分支，以及如何与团队成员进行远程协作。
创建 Pull Request（含示例）
假设您发现项目 README 文件的开头一句有错误。您希望在不影响主分支的情况下修复它。请按以下步骤操作：
步骤 1：创建新分支
进入项目文件夹，打开终端运行下面的命令。这行命令会创建一个新分支。
步骤 2：进行修改
打开代码编辑器中的
README.md文件，修正错别字，并保存文件。步骤 3：提交变更
使用以下命令暂存并提交更改：
步骤 4：将分支推送到 GitHub
将该分支上传到代码库。
步骤 5：打开 GitHub 并创建 pull request
现在打开您的 GitHub 账户，按以下步骤进行：
在 GitHub 上进入您的代码库。
为您推送的分支选择“Compare & pull request”提示。
添加标题，例如 Fix typo in README，并可选地写一段简短描述。
选择基准分支（通常为
main），并与您的功能分支进行对比。步骤 6：请求评审并提交
如果您的项目涉及其他开发者，您可以请求评审者，或在项目使用标签时添加标签。然后点击Create pull request。
查看我们的项目 Performing a Code Review，了解如何在代码上线前进行评审与修改。
Pull Request 最佳实践
以下最佳实践可帮助您在创建 pull request 时确保高质量开发：
不同 Git 工作流中的 Pull Request
下面快速概述不同团队设置如何使用 pull request。
功能分支（Feature branching）：在小团队和私有代码库中很常见。该工作流为每个功能创建一个新分支。
Fork 工作流：用于开源项目。此工作流要求贡献者将主仓库 fork（复制）到自己的账户中，在 fork 中进行更改，然后向原仓库发起 pull request。
GitFlow：一种结构化工作流，使用
main、develop、release和hotfix等长期分支。常见于发布周期更复杂的大型团队。Pull Request 礼仪
礼仪同样重要，pull request 也有其特定的行为准则：
进阶 Pull Request 工作流与最佳实践
如果您是有经验的开发者，想让协作更顺畅、提升代码质量并扩展 pull request 流程，以下实用技巧可帮助您优化工作流。
更聪明的工作流
不同的 Git 工作流对 pull request 的处理各有不同。正如前文所述，功能分支因其简单性非常适合小团队，但随着团队壮大，维护难度可能上升。
Fork 工作流推荐用于开源项目，但在同步与评审外部贡献时可能引入额外开销。类似地，GitFlow 适用于节奏较快的开发，不过其复杂性也可能放慢流程。
自动化与集成
现代 pull request 配有 CI/CD 检查，通过集成持续集成工具在每个 PR 上运行测试、代码规范检查并部署预览，从而自动化质量门槛，确保只有符合既定标准的代码才会被合并。
GitHub Actions 与 GitLab Pipelines 等平台也支持自动化。这些流程包括运行单元测试、构建与部署预览环境，减少手工操作并及早发现问题。
优化评审
始终让 pull request 小而聚焦，以便快速且全面地评审。使用包含“变更内容”“如何测试”等清晰字段的模板，能帮助贡献者提供简明且相关的信息，使评审更高效。
此外，请注意以提问代替命令式表达有助于建立建设性对话与学习。若您为评审设定周转时间，将有助于保持流程可预期并避免延误。
度量与现代工具
我也建议跟踪 PR 规模、评审用时与合并率，以识别瓶颈并提升工作流效率。为便于评审与合并，可尝试使用“叠放式（stacked）pull request”，将大型功能拆分为多个彼此关联、逐步构建的 PR。
此外，您可以在使用 pull request 时集成如 GitHub Copilot 或 CodeWhisperer 等 AI 工具，它们可帮助您尽早突出潜在问题并给出修正建议。
Pull Request 与 Merge Request 的区别
在 GitHub 与 GitLab 中，Pull Request（PR）与 Merge Request（MR）常被交替使用。尽管用途相同，但各平台的处理方式有所不同。
下表比较了 PR 与 MR，以突出这些差异。
方面
Pull Request（GitHub）
Merge Request（GitLab）
术语
请求拉取更改
请求合并更改
主要用途
提出、评审并合并代码更改
提出、评审并合并代码更改
典型用户
开源开发者、中小型团队
DevOps 密集型团队、企业与私有仓库
CI/CD 集成
GitHub Actions（可选，需配置）
默认内置 CI/CD
草稿支持
原生支持 Draft PR
通过“Draft”标签或 WIP 前缀支持
合并审批
基础的评审者与审批设置
高级规则：多审批人、审批流水线
合并策略
合并提交、压缩合并或变基
类似选项，并可配置合并方式限制
工作流理念
以开发者为中心，灵活
聚焦 DevOps，开发与运维深度集成
结语
对于任何严肃的项目，pull request 都是必须掌握的。正如您所见（也希望您已认可），它让团队能够协作地评审、讨论并改进代码。
持续提升您的开发者技能。查看我们的 Git Fundamentals 与 GitHub Foundations 技能路径，全面精通 Git 相关内容。