工程与协作
合并请求Pull Request
你可能会问
合并请求到底是什么？自己合并不行吗，为什么要「请求」？
简单来说
请求团队审查一组代码修改，并在确认后合并到目标分支。
直接推主线先发 PR进主线前，有没有人看
问题在线上爆问题被评审拦拦在门外，代价最小
01 · 先这样理解
把抽象概念放进真实场景
请求团队审查一组代码修改，并在确认后合并到目标分支。
换个角度想PR 像论文投稿：稿子写完不能直接见刊，审稿人提意见、你修改，通过了才发表。主线就是那本期刊，进去的都过了同行评审。
02 · 点击演示
AI 的大改动，直接进主线还是先过评审？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 这一步不存在——
改完直接 push，没人知道改了什么PR #42标题重构支付模块内容完整 Diff + 改动说明 没有闸门
改动已经躺在主线上了
自动检查测试✓ 通过构建✓ 通过第一个「评审」是线上用户
老账户的余额显示成了 0
同事的评论第 87 行「老账户没这个字段吧？」你补上兼容逻辑 ✓- 半夜回滚事故报告加熬夜修复，代价最大化问题总会被发现，差别在时机和代价干净合入兼容问题在评审里就解决了多等一晚，省一场事故
1 / 4
Open · 分支改完，发起 PR
03 · 放进真实任务
什么时候会遇到它
AI 代码的闸门
Agent 写的代码先出 PR，人看过 Diff 再进主线。
团队知识流动
评审里的讨论，让整个团队理解这次改动。
出问题可追溯
半年后回看，当时为什么这么改，PR 里全有。
04 · 想一想
用一个问题检查理解
深夜赶工，AI 生成了一个大改动，测试也绿了，能不能跳过 PR 直接推主线？
查看答案
测试绿只说明没破坏已有用例，用例覆盖不到的坑机器看不见。越是大改动、越是深夜，越需要第二双眼睛——发 PR，明早让同事看过再合。
最容易踩的坑
PR 评审不是走形式。「LGTM 秒批」的团队，主线和没有评审时一样脆——评审的价值全在认真看 Diff。