17、团队协作基础：Pull Request（PR）与 Merge Request（MR）的创建、审查、合并流程
聊到团队协作，就绕不开 Pull Request 和 Merge Request。说白了，它们俩是同一件事——只是叫法不同。GitHub 叫 PR，GitLab 叫 MR。我刚开始带团队那会儿，大家还习惯直接往 master 上推代码，结果嘛……你想想看，谁都不敢保证自己写的代码不出问题。
PR/MR 的核心价值，就是给代码加一道「人工审核」的关卡。它不只是流程，更是一种文化。今天我就把这块掰开揉碎了讲清楚。
PR 和 MR 到底是个啥？
Pull Request，字面意思是「拉取请求」。你写好代码，想合到主分支，得先发个请求，让别人看看。Merge Request 同理，只是 GitLab 的命名偏好。
我个人习惯用 GitHub，所以下文统一叫 PR。但你要知道，MR 的流程几乎一模一样。
核心逻辑：PR 不是合并动作，而是「请求合并」的讨论空间。代码合入之前，所有问题都在这里暴露、讨论、修复。
PR 的生命周期：从创建到合并
一个标准的 PR 流程，大概分五步。我画了张图，你先看个全貌。
第一步：创建分支，写好代码
PR 的前提是分支。你永远不要在 master 或 main 上直接改代码。我见过有人图省事，直接在 master 上改了一行，然后推上去……结果那天整个团队都在等他回滚。
正确的做法是：
# 从最新的主分支拉出功能分支
git checkout main
git pull origin main
git checkout -b feat/user-login-optimization分支命名要有意义。我个人习惯用 feat/、fix/、refactor/ 做前缀，后面跟简短描述。这样一看分支名，就知道这 PR 是干嘛的。
第二步：提交 PR，写好描述
代码写完了，commit 也推上去了。这时候在 GitHub 上点「New Pull Request」，选好源分支和目标分支。
嗯，这里要注意——PR 的描述比代码本身更重要。为什么？因为审查者要通过描述来理解你的意图。
我的 PR 模板：
- 标题：[类型] 简短描述（如：[feat] 优化用户登录流程）
- 背景：为什么要做这个改动？
- 改动内容：改了哪些文件，核心逻辑是什么
- 测试方式：怎么验证这个改动是正确的
- 关联 Issue：Closes #123
我曾经见过一个 PR，标题就写「fix bug」，描述是空的。你想想看，审查者得花多少时间去猜你到底改了啥？
第三步：代码审查（Code Review）
这是 PR 流程的灵魂。审查者会逐行看你的代码，提意见、问问题。你可能会觉得烦，但换个角度想——有人帮你免费找 bug，多好的事。
审查时我一般关注这几点：
| 审查维度 | 具体问题 |
|---|---|
| 逻辑正确性 | 代码能实现预期功能吗？有没有边界情况没处理？ |
| 代码风格 | 符合团队规范吗？命名是否清晰？ |
| 安全性 | 有没有 SQL 注入、XSS 等风险？ |
| 性能 | 有没有不必要的循环、重复查询？ |
| 可维护性 | 三个月后别人能看懂这段代码吗？ |
避坑指南：我曾经因为没检查 PR 中的数据库查询，上线后导致慢查询把数据库拖垮了。从那以后，我审查代码时一定会看 SQL 执行计划。你也别忽略这个环节。
第四步：修改与重新提交
审查者提了意见，你怎么办？别急着怼回去。先想想对方的建议有没有道理。
修改完成后，直接 push 到同一个分支。PR 会自动更新，审查者能看到新的 commit。不需要重新创建 PR。
# 在本地修改代码
git add .
git commit -m "fix: 根据 review 意见优化查询逻辑"
git push origin feat/user-login-optimization这里有个小技巧：如果修改比较多，可以在 PR 评论区 @ 审查者，说一句「已修改，麻烦再看一下」。这样对方会收到通知，不会晾着你的 PR 不管。
第五步：合并与关闭
审查通过了，CI 也绿了，这时候就可以合并了。GitHub 和 GitLab 都提供了几种合并方式：
- Create a merge commit：保留所有 commit 历史，适合记录完整开发过程
- Squash and merge：把所有 commit 压缩成一个，保持主分支历史干净
- Rebase and merge：将 commit 变基到目标分支顶部，历史呈线性
我个人偏好 Squash and merge。为什么？因为开发过程中的「fix typo」「wip」「test」这些 commit 没有保留价值。合并后主分支上只看到一个清晰的 commit，多舒服。
合并后别忘了：删除远程分支。GitHub 上合并 PR 时有个「Delete branch」按钮，点一下。分支留着只会让列表越来越乱。
PR 审查中的常见问题
我带过不少团队，发现 PR 流程中容易踩几个坑：
- PR 太大：一个 PR 改了几十个文件，审查者看到就头疼。我建议一个 PR 控制在 200 行以内，专注一件事。
- 审查流于形式：有人点个「Approved」连代码都没看。这比不审查更可怕。
- 长时间不处理：PR 挂了一周没人管。团队应该约定：24 小时内必须给出初步反馈。
说白了，PR 流程好不好用，不取决于工具，取决于人。工具只是辅助，真正的价值在于团队形成了「互相 review、共同进步」的文化。
好了，PR 和 MR 的核心流程就这些。你动手创建一个试试，走一遍流程，比看十遍文章都管用。