很多刚进入团队开发的程序员，第一次听到 Pull Request，都会有点迷糊。
代码不是已经 git push 上去了吗？
为什么还要发 PR？
PR 是不是就是“提交代码”？
Reviewer 又到底在看什么？
一句话说清楚：
Pull Request 不是提交代码，而是请求团队审查并合并代码。
它真正解决的问题不是“代码怎么传上去”，而是“这段代码能不能进入主分支”。
PR 是什么？
Pull Request，简称 PR，中文常叫“拉取请求”或“合并请求”。
在 GitHub 里通常叫 Pull Request。
在 GitLab 里通常叫 Merge Request。
名字不同，本质很接近。
它表达的是：
我在 feature 分支完成了一段代码，请团队帮我检查，确认没问题后合并到 main。
比如：
feature/login ---> main
你不是直接把代码塞进 main，而是先发起一个请求。
团队成员会在这个请求里看到：
- 你改了哪些文件
- 每个文件改了什么
- 提交记录是什么
- 是否通过自动化测试
- 是否有人审查通过
- 是否存在冲突
所以，PR 是代码进入主分支前的一道门。
为什么不能直接合并？
如果每个人都能直接 push 到 main，短期看很快，长期一定出问题。
常见风险包括：
- 半成品功能进入主分支
- Bug 没人发现
- 同事代码被覆盖
- 测试没跑就上线
- 需求理解偏差没人纠正
- 安全问题直接混进生产代码
PR 的价值，就是把“个人提交”变成“团队确认”。
一个成熟团队通常会要求：
- 必须走 PR
- 至少一人 Review
- CI 测试通过
- 无冲突
- 符合代码规范
- 关键模块需要负责人审批
这不是形式主义，而是降低风险。
一个标准 PR 流程
假设你要开发登录功能。
你通常会这样做：
git checkout main
git pull origin main
git checkout -b feature/login
开发完成后提交：
git add .
git commit -m "feat(login): add sms login"
git push origin feature/login
然后在 GitHub、GitLab 或 Gitee 上发起 PR：
feature/login -> main
接下来会进入审查流程：
提交代码
-> 发起 PR
-> 自动化测试
-> Code Review
-> 修改反馈
-> 再次提交
-> 审查通过
-> 合并 main
注意：PR 不是一次性动作。
Reviewer 提意见后，你可以继续在 feature/login 分支上提交代码。PR 页面会自动更新。
这也是 PR 很方便的地方：所有讨论、修改、测试结果都集中在同一个地方。
Reviewer 到底在看什么？
很多新人以为 Reviewer 只是看看代码有没有语法错误。
其实不是。
真正的 Code Review 会关注很多层面：
- 需求是否实现对了
代码有没有解决真正的问题？有没有理解偏需求？
- 逻辑是否可靠
边界条件、异常情况、空值、并发、权限有没有处理？
- 代码是否可维护
命名是否清楚？结构是否合理？有没有过度复杂？
- 是否影响其他模块
改登录功能，会不会影响注册、鉴权、用户信息接口？
- 是否有安全风险
有没有泄露 Token？有没有权限绕过？有没有敏感数据打印？
- 测试是否足够
有没有补测试？关键路径有没有覆盖？
所以，PR 审查不是挑刺，而是帮团队在代码进入主分支前多看一眼。
很多线上问题，其实在 PR 阶段就能被发现。
怎么写一个高质量 PR？
一个好的 PR，不应该只丢一堆代码给别人猜。
你需要把上下文说清楚。
推荐 PR 描述包含这些内容：
## 背景
本次 PR 增加手机号验证码登录功能。
## 改动内容
- 新增短信验证码登录接口
- 新增登录页面表单校验
- 增加 token 刷新逻辑
- 补充登录失败场景测试
## 验证方式
- pnpm test
- 手动测试手机号登录成功/失败场景
## 风险点
- token 刷新逻辑会影响现有登录态
- 需要关注验证码过期场景
这种 PR 会让 Reviewer 很舒服。
他不用从零猜你的意图，也能更快判断重点。
PR 写得越清楚，Review 越高效。
PR 太大，是最常见的问题
很多 PR 难 Review，不是因为代码差，而是太大。
一个 PR 里同时包含：
- 新功能
- 重构
- 样式调整
- 依赖升级
- 顺手修 bug
- 格式化全文件
Reviewer 会很痛苦。
更好的方式是拆小：
PR 1：新增登录 API
PR 2：新增登录页面
PR 3：补充登录测试
PR 4：重构鉴权工具函数
小 PR 的好处很明显：
- 更容易理解
- 更容易发现问题
- 更容易回滚
- 更容易快速合并
- 冲突概率更低
记住一句话：
PR 不是越完整越好，而是越聚焦越好。
收到 Review 意见怎么办？
收到 Review 意见，不要本能防御。
Reviewer 不是在否定你，而是在帮代码变得更稳。
常见回复方式：
已修改，增加了空值判断。
这里我保留当前写法，是因为接口需要兼容旧版本。
这个建议有道理，我单独拆一个 PR 处理重构。
好的 PR 讨论应该围绕代码和需求，而不是情绪。
如果你不同意某条意见，也可以解释原因。
PR 本来就是协作场所，不是单向审批。
合并之后就结束了吗？
PR 合并到 main 后，还可以做几件事：
- 删除 feature 分支。
git branch -d feature/login
远程分支也可以在平台上删除。
-
确认 main 上 CI 正常。
-
如果涉及上线，继续观察日志和监控。
-
如果 PR 留下技术债，及时创建后续任务。
PR 合并不是终点，它只是代码进入主线的节点。
真正重要的是：合并后的代码是否稳定运行。
PR 命令速查
git checkout main
# 切换到主分支
git pull origin main
# 拉取最新主分支
git checkout -b feature/login
# 创建功能分支
git add .
# 添加修改
git commit -m "feat(login): add sms login"
# 提交代码
git push origin feature/login
# 推送功能分支到远程
git status
# 查看当前状态
git log --oneline
# 查看提交历史
git diff main
# 查看当前分支相对 main 的改动
结尾：PR 是团队协作的安全门
Pull Request 不是多余流程，也不只是代码提交按钮。
它真正做的是：让代码进入主分支之前，经过讨论、测试、审查和确认。
这篇文章可以总结成以下三点：
- PR 的本质是请求团队审查并合并代码，不等于简单提交代码。
- 高质量 PR 要说明背景、改动内容、验证方式和风险点。
- 小而聚焦的 PR，比巨大而混杂的 PR 更容易 Review，也更安全。
本文由 楸木 原创，转载请注明出处。