Pull request：从创建到合并

本文将介绍 Pull Request（PR）是什么，以及它如何用于讨论更改。您还会学会直接在 IDE 中创建和查看 PR，并了解写好 commit 的三条规则。这些基础很重要：Claude Code 可以替您准备 pull request 并发表评论；只有理解 PR 是什么、为什么需要它，才能有意识地使用这些能力。

示例和界面截图基于 JetBrains IDE；操作名称和位置可能因您使用的版本而异。练习时请使用单独的练习 repository。在实际项目中，请遵循项目自身关于分支、提交和推送更改的规则。

为什么需要 Pull Request

在团队中，把更改合入共享分支之前先讨论一番很有帮助。Pull request 将待合入的 diff、评审意见和检查结果集中在一处。个人项目也可以用它，在合并前检查自己的改动。

使用 PR 时，您首先会创建一个合并请求。GitHub 称之为 Pull Request，其他一些平台则称为 Merge Request。具体流程由团队决定。

Pull Request 是一项正式请求："请从我的分支 pull 更改，并将它们 merge 到主分支"。但它不只是请求，还是一个在代码进入 main 之前讨论、检查和改进代码的平台。

Pull Request 的标准工作流程

我们按步骤看看，开发新功能时通常会经历怎样的流程。

创建分支前，请先检查源分支，以及它相对于 GitHub 上目标分支的 commit 列表。新 PR 不应带入无关的本地 commit。不要为了"同步"就自动推送它们：请选择正确的任务基准，并单独保留之前的工作。

步骤 1：为新任务创建分支。本文介绍的 PR 流程从一个独立分支开始。假设我们要添加一份贡献者指南，就创建分支 feature/add-contribution-guide。

步骤 2：进行更改并将分支推送到 GitHub。在新分支中创建文件 CONTRIBUTING.md（创建后点击 Add），并在其中写下给其他开发者的说明。然后执行 Commit and Push，填写清晰的 message，例如 docs: Add contribution guide。

这一步很关键。Pull Request 基于远程服务器上已经存在的分支创建。因此，创建 PR 之前，必须先将新分支 push 到 GitHub。

在 IDE 中创建 Pull Request

请检查比较的两端：base 是接收更改的分支，compare/head 是包含您工作的分支。创建 PR 之前，请查看 commit 列表和 diff。

现在，您的分支已经在 GitHub 上，可以创建 Pull Request 了。

步骤 1：打开 Pull Requests 标签页。在 IDE 左侧边栏找到 Pull Requests 标签页。打开后点击 + 图标（或 Create Pull Request 按钮）。

步骤 2：填写 PR 信息。IDE 会打开一个便于操作的界面。请认真填写其中的主要字段：

1. 标题 - IDE 通常会填入分支名或最近一次 commit message；请确认标题简洁清楚，能概括更改内容；
2. 说明 - 向同事清楚解释您做了什么以及为什么要做；
3. 评审者（Reviewers） - 您邀请来检查更改的人。是否必须获得批准，由 repository 的规则决定；
4. 负责人（Assignees） - 通常在这里填写您自己，作为作者和评审后修改的负责人。

点击 Create Pull Request 前，请再次检查 base、head 和 diff。如果工作尚未准备好接受评审，并且平台支持，可以创建 Draft PR。拥有 repository 访问权限的人都能看到普通 PR 和 draft。

Code review：检查与讨论

创建 PR 后，最重要的阶段就开始了：code review。同事可以打开您的 PR，查看所有更改并留下评论。

所有讨论都会直接显示在 IDE 的 Pull Requests 标签页中。如果有人针对某一行代码发表评论，您会收到通知，可以直接回复，无需切换到浏览器。

如果评审要求您修改，应该怎么做？很简单：不必创建新的 PR。在这个 PR 对应的源分支上修改代码，创建新的 commit 并推送即可。GitHub 上的 Pull Request 会自动更新，新 commit 也会加入现有讨论。

完成工作：合并并删除分支

所有评审意见都处理完、团队也批准了更改（即获得 approval）后，就可以合并 Pull Request。通常由资深开发者执行；如果您在 repository 中拥有相应权限，也可以自行合并。

步骤 1：合并。检查评审意见、必需的批准和检查状态。如果项目规则和您的权限允许合并，请按项目约定选择可用方式（merge、squash 或 rebase）并确认。更改将进入 PR 的目标分支，本例中是 main。

步骤 2：删除分支。合并后，feature 分支就不再需要了，建议删除，以免 repository 中留下多余分支。GitHub 会提供 Delete branch 按钮。

合并后，请在本地切换到 main，获取最新更改，并确认 PR 的内容已经合入。之后，如果任务分支中没有需要保留的工作，就可以删除它。如果 IDE 不允许按常规方式删除，请先查明原因，尤其是在 squash 或 rebase 之后。

写好 commit 的三条规则

好的 commit 不仅要有清楚的 message，内容也要恰当。遵循下面三条简单规则，能让更改历史保持清晰、有用。

规则 1：写清楚 commit message

您的 commit 是留给团队和未来自己的说明。如果历史记录里全是 "fix" 或 "update"，就很难派上用场。Conventional Commits 是一种常见格式，它建议采用这样的结构：

<类型>: <简短说明>

类型 - 用一个简短的词说明更改类别：

• feat - 新功能；
• fix - 修复问题；
• docs - 文档更改；
• style - 不影响逻辑的格式调整；
• refactor - 调整代码结构，不增加新功能，也不修复问题；
• test - 添加或修复测试；
• chore - 日常维护任务（更新依赖项、配置 build）。

示例：

• 不推荐： fixed bug
• 推荐： fix: Correct user login validation
• 不推荐： readme
• 推荐： docs: Update installation instructions

规则 2：一个 commit 对应一项逻辑更改

不要把 bug 修复、新功能和旧代码重构塞进同一个 commit。这样的 commit 很难评审，也几乎无法安全撤销。每个 commit 都应只解决一项具体任务。

• 不推荐：一个名为 "Update user page" 的 commit 同时添加头像字段、修复用户名验证并更改按钮颜色；
• 推荐：拆成三个独立的 commit：
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. feat: Update button colors on user page

如果您一时改动太多，导致同一个文件里混有多项更改，IDE 允许只 commit 文件的一部分：在 Commit 窗口中展开文件，只勾选与当前任务相关的代码片段（chunks）。

规则 3：检查更改结果

合并前，请执行适合这项更改的检查，并查看实际结果。文档修改和新逻辑需要的检查并不相同。

如果 repository 已配置自动检查，PR 会显示检查状态。绿色标记表示某项已运行的检查通过了，并不代表没有任何问题。请查看运行了哪些检查，还有哪些内容未经检查。自动化配置是另一个话题。

Claude Code 如何参与 PR 流程

PR 流程正是 Claude Code 特别能帮上忙的地方。您可以留意这些能力：

• Claude 可以根据您的分支创建 pull request，并准备好标题和说明；在 GitHub 上创建 PR 前，您可以先检查这些文字；
• 可以检查 PR 中的更改并发表评论，帮您先把一道关；
• 可以按照项目规则协助编写 commit message；
• 可以帮助解读已配置的检查结果，并指出尚未检查的部分。

上一篇：Git 分支与合并 · 下一篇：Git 中的更改撤销与恢复