Pull Request

在前面的章节中，我们已经学会了一个常见的开发流程：从 main 创建新的 Branch，在自己的 Branch 中修改代码、Commit，然后 Push 到 GitHub。接下来最重要的一步，就是把这些修改合并回 main。

在实际团队开发中，通常不会直接在本地执行：

git merge feature/login

然后立即 Push 到 main。更常见的方式是先在 GitHub 上创建一个 Pull Request（PR）。

Pull Request 可以简单理解成：

我已经在自己的 Branch 中完成了一些修改，现在希望把这些修改合并到另一个 Branch，请大家先看一下。

例如，你正在开发一个登录功能：

main → feature/login

开发完成后，你已经执行：

git add .
git commit -m "Add login feature"
git push -u origin feature/login

现在 GitHub 上已经有了 feature/login。接下来就可以在 GitHub 中创建一个 Pull Request，请求把：

feature/login

合并到：

main

为什么不直接修改 main？

如果只有一个很小的个人项目，直接修改 main 并不会马上带来严重问题。但在团队项目中，如果每个人都直接向 main Push 代码，就很难在合并之前检查这些修改。

使用 Pull Request 后，整个流程会变成：

创建 Branch → 修改代码 → Commit → Push Branch → 创建 Pull Request → Code Review → 自动检查 → Merge

这样其他开发者可以在代码进入 main 之前检查它，也可以讨论某些实现是否合适。

创建 Pull Request

假设你已经把：

feature/login

Push 到 GitHub。

打开 Repository 后，GitHub 通常会提示这个 Branch 最近有新的 Push，并提供创建 Pull Request 的入口。你也可以进入 Repository 的 Pull requests 页面，然后选择创建新的 Pull Request。

创建时最重要的是确认两个 Branch：

base:    main
compare: feature/login

其中 base 是“希望代码最终进入的 Branch”，而 compare 是“包含当前修改的 Branch”。

可以简单理解成：

feature/login → Pull Request → main

PR 标题和描述应该写什么？

Pull Request 通常会有一个标题和描述。

标题应该简单说明这次修改做了什么，例如：

Add login page
Fix payment timeout
Improve search results

描述则可以说明更多背景，例如为什么需要这个修改、主要修改了哪些内容，以及测试过哪些功能。

对于小项目，描述不需要写得非常正式。只要能帮助 Reviewer 理解这次修改即可。

例如：

This PR adds the login page and basic form validation.

Changes:
- Add email and password fields
- Add required-field validation
- Show an error message when the form is incomplete

Pull Request 的核心不是写一篇长文，而是让别人能够快速理解“为什么有这个 PR”和“这个 PR 改了什么”。

在 PR 中查看代码差异

创建 PR 后，GitHub 会把 Branch 之间的差异显示出来。你可以看到哪些文件被修改、哪些代码被新增，以及哪些代码被删除。

这和前面使用 VS Code 查看 Diff 的概念是一样的，只不过现在这些 Diff 放到了 GitHub 上。

例如：

feature/login → 与 main 比较 → Files changed

在 Files changed 页面中，Reviewer 可以直接查看代码差异，而不需要把整个项目重新下载下来。

因此，一个很好的习惯是：创建 PR 以后，自己也先看一次 Files changed。这样经常能发现一些遗漏，比如临时测试代码、无关文件或者本来不打算提交的修改。

什么是 Code Review？

代码审查（Code Review） 指的是其他开发者检查你的修改，然后提出意见。

例如 Reviewer 可能发现：

if (password.length < 4) {

并留言：

Should the minimum password length be 8 instead?

或者发现一段逻辑重复，希望你进行简化。

Code Review 并不是说明代码一定“写错了”。它更多是一种协作方式，可以帮助团队提前发现 Bug、保持代码风格一致，也可以让其他人了解项目中发生了什么修改。

PR 创建以后还能继续修改吗？

可以。

假设你创建 PR 后，Reviewer 让你修复一个问题。你不需要关闭 PR 再重新创建，只需要继续在原来的 Branch 中修改：

git switch feature/login

修改后：

git add .
git commit -m "Fix login validation"
git push

新的 Commit Push 到同一个 Branch 后，GitHub 上原来的 Pull Request 会自动更新。

也就是说：

PR
 ↑
 |
feature/login
 ↑
 |
新的 Commit

只要 Branch 没有变，PR 会持续显示这个 Branch 的最新修改。

Merge Pull Request

当 Code Review 完成，并且自动检查也通过后，就可以把 PR Merge 到 main。

在 GitHub 中通常会看到类似：

Merge pull request

的按钮。

Merge 完成后：

feature/login → main

登录功能就正式进入了主分支。

这时本地的 main 可能还没有最新代码，所以回到本地后通常需要：

git switch main
git pull

这样本地 main 才会获得刚刚在 GitHub Merge 的修改。

Merge 后可以删除 Branch

一个 Feature Branch 完成使命以后，通常就可以删除。

GitHub 在 Merge PR 后一般会提供：

Delete branch

按钮。

本地也可以删除：

git branch -d feature/login

删除 Branch 不会删除已经 Merge 到 main 中的代码。

一个完整的 PR 流程

整个过程可以概括成：

git switch main → git pull → git switch -c feature/login → 修改代码 → git add . → git commit → git push → 创建 Pull Request → 查看 Diff → Code Review → 修改并继续 Push → Merge → 删除 Branch

这已经是很多团队最基础的 GitHub 协作方式。