10.9 Pull Request工作流
Tip
没经过 Code Review 的代码，就像没经过安检的行李，谁知道里面藏着炸弹还是糖果？
1. 为什么要学这个?
在正规团队，你永远没有权限直推 main 分支。
你试图 git push origin main，终端会冷冷地甩给你一行红字：
remote: error: GH006: Protected branch update failed.
这就像你想进金库，但保安把你拦住了。 你需要填写申请表，说明你带了什么，经过审批后，由专门的人帮你放进去。 这张申请表，在 GitHub 叫 Pull Request (PR)，在 GitLab 叫 Merge Request (MR)。
2. 核心概念：Code Review (代码审查)
PR 真的只是为了合并吗？
不。PR 是程序员最好的学校。 当你发起 PR 后，资深工程师会逐行阅读你的代码，并在旁边评论：
- "这里会内存泄漏。"
- "这个变量名起得像天书。"
- "能不能抽出一个组件？"
这是免费的一对一私教课。
3. 解决方案 (HOW)
标准 PR 流程
- 开发：在
feature/login分支写好代码并 push。 - 发起：在 GitHub 页面上，点击醒目的绿色按钮 Compare & pull request。
- 描述：(关键) 写清楚你改了什么，最好贴上截图或录屏。
- Review：邀请队友 Review。队友可能会：
Comment: 提出疑问。Request changes: 打回重做。Approve: 通过。
- 修改：你在本地修改代码，再次
git push（PR 页面会自动更新，不用重新发）。 - 合并：所有灯变绿后，点击 Squash and merge。
协作泳道图
graph TD
Dev["开发者"] -->|"1. Push branch"| GitHub["GitHub"]
GitHub -->|"2. Create PR"| Reviewer["Reviewer (审查者)"]
Reviewer -->|"3. 发现 Bug (Request Changes)"| GitHub
GitHub -.->|"通知"| Dev
Dev -->|"4. Fix & Push"| GitHub
GitHub -->|"5. 自动更新 diff"| Reviewer
Reviewer -->|"6. Approve"| GitHub
GitHub -->|"7. Merge to Main"| Main["Main 分支 (生产环境)"]
style GitHub fill:#e3f2fd,stroke:#1565c0
style Main fill:#c8e6c9,stroke:#2e7d32
4. 真实案例
Story
价值一千万的 WHERE 子句
某金融公司的后端工程师写了一个清理过期日志的脚本。
逻辑是：DELETE FROM logs WHERE created_at < '2023-01-01'。
但他在写 SQL 时，手抖漏掉了 WHERE，变成了 DELETE FROM logs。
这个脚本如果运行，全公司的日志表会被清空。
甚至 DELETE 操作太慢，还会锁死数据库，导致服务不可用。
谁救了公司？
是 Code Review。
他的同事在 Review 代码时，一眼看到了这行没有 WHERE 的 SQL。
一个简单的评论："Bro, you trying to kill us?"
这一刻，PR 机制挽救了一场史诗级的灾难。
Vibe 心法： 不要把 "Request changes" 当作批评。 每一次被打回，都是队友在帮你排雷。 感谢那个在 PR 里对你挑三拣四的人，他在教你如何不把公司搞垮。
5. 本章小结
- 安检机制：PR 是保护主分支的最后一道防线。
- 写好描述：PR 的描述越清晰，Review 越快（贴图是美德）。
- 拥抱反馈：Review 意见不是针对你个人，是针对代码。