一、为什么需要合并请求？
先问一个问题：master 主分支应该是什么状态？
答案是：永远稳定，随时可部署。
master 分支里的代码，应该经过测试、经过评审，没有任何未完成的功能，没有任何已知的 bug。任何时候，你都可以基于 master 发布一个新版本。
但如果没有约束，每个人都直接往 master 提交代码，会发生什么？
- A 写到一半的代码合进去了，项目编译不过
- B 改了一个功能，但没考虑边界情况，线上出 bug
- C 和 D 改了同一个文件，互相覆盖
混乱，是必然的。
所以，我们需要一个机制：代码不能直接合入 master，必须经过其他人的评审，评审通过后才能合并。
这就是**合并请求（Merge Request）**存在的意义。
二、合并请求是什么？（GitLab 叫 MR，GitHub 叫 PR）
不同平台叫法不同：
- GitLab 里叫Merge Request（合并请求，简称 MR）
- GitHub 里叫Pull Request（拉取请求，简称 PR）
核心逻辑完全一样：你请求项目维护者把你的分支代码'拉'进主分支，在拉进去之前，大家先看看代码写得怎么样。
三、什么时候需要代码评审？
不是所有修改都需要评审，但以下几种场景，强烈建议走评审流程：
1. 大功能开发，代码量很大
改动越多，越容易出问题。让其他开发者帮你过一遍，能发现很多你自己发现不了的 bug。
2. 初级开发者提交代码
新人刚接触项目，对代码规范、业务逻辑可能不够熟悉。资深开发者评审一下，既能保证代码质量，也能帮新人快速成长。
3. 跨领域修改
比如一个后端工程师修改了前端代码。让前端专家看一眼，能避免写出不符合前端规范的代码。
代码评审不只是在'挑错'，更是一次学习和交流的机会。 评审者可以告诉开发者：'这个地方可以用更好的写法''这个逻辑有边界漏洞''这里有个隐藏坑'。
四、合并请求的完整流程
第一步：开发者完成功能开发
你在自己的功能分支（比如 feature/用户登录）上完成了开发，本地测试通过，觉得可以合入 master 了。
第二步：把分支推送到远程
git push --set-upstream origin feature/用户登录
第三步：在代码平台上创建合并请求
进入 GitLab/GitHub，找到你的分支，点击'创建合并请求'。
需要确认两件事：
- 源分支：你的功能分支（
feature/用户登录） - 目标分支：master
然后填写标题和描述，说明这次改了啥。可以指定某个同事作为评审人，也可以不指定，让团队里谁都行的人来审。
第四步：评审人审查代码
评审人打开合并请求，看到你所有的变更、所有的提交记录。
他可以做两件事：
- 如果代码有问题：添加评论，指出问题所在，然后拒绝合并请求
- 如果代码没问题：批准合并请求，然后执行合并操作
这里有个重要原则：评审人一般不会直接修改你的代码，而是留评论让你自己改。 这样你才能从错误中学习，下次写得更好。
