必须同步配置Push Rules、Required Approvals和Status checks三项，否则GitLab分支审查形同虚设：前者禁直接推送，中者强制双人审批并刷新旧批注，后者绑定唯一命名的CI关键任务。
没有审查机制的合并，等于把生产环境当测试沙盒用。线上故障率不是靠“运气低”降下来的，而是靠在合并前卡住三类问题：逻辑冲突、语义错误、权限越界。Git 本身不提供审查能力，但所有主流平台（GitLab/GitHub）都依赖 Merge Request + Protected Branches + Required Approvals 这三层组合拳来落地审查。
为什么直接 push 到 main 会放大故障率
直接 git push origin main 绕过审查，意味着以下风险全部失效：
- 没人检查你改的那行
if (status === 'active')是否漏掉了null判断 - 没人确认你新增的 API 路由是否和已有中间件冲突
- 没人核对 CI 流水线里那个被注释掉的
test_payment_flow是否真该跳过 - 更关键的是：一旦出错，回滚依赖人工记忆 commit hash，而不是靠可追溯的 MR 记录
GitLab 中必须启用的三项保护配置
仅开启 Protected Branches 不够，必须同步配置以下三项，否则审查形同虚设：
-
Push Rules：禁止force-push，禁用直接推送，只允许通过 MR 合并 -
Required Approvals：至少设置2个审批人，且启用Dismiss stale approvals when new commits are pushed，避免旧审批被新代码覆盖 -
Status checks：绑定 CI 流水线中的关键 job 名，例如unit-test和security-scan，注意 job 名必须全局唯一，否则状态检查会误判
GitHub 上绕过审查的常见漏洞点
即使开了 Require pull request reviews before merging，仍可能被绕过：
- 管理员默认豁免 —— 必须手动勾选
Include administrators才生效 - 分支规则匹配顺序错误：比如同时存在
main和*-release规则，而main-release分支会被后者覆盖，导致审查失效 - 未启用
Require linear history：合并时产生merge commit会稀释变更上下文，让 Code Review 失去聚焦点
真正起作用的不是“有没有审查”，而是“审查能否被绕过”。哪怕只漏掉一个配置项，就可能让一次 git merge 直接变成线上事故的起点。
