2. GitLab代码质量治理的架构与组件

GitLab 的代码质量治理并不是某一个功能按钮，而是一组围绕“代码变更”构建的协同机制。理解这套机制的关键，是先看清一次 Merge Request（MR）从创建到合并，究竟经过了哪些组件的接力：CI/CD 负责自动验证，Code Review 负责人工判断，Protected Branch 负责守住入口，Approval Rules 负责把“谁同意才能过”变成硬约束。它们不是并列的功能清单，而是一条有先后、有依赖、有反馈回路的治理链。

一、五个核心组件在治理链中的位置

可以把一次代码变更的旅程拆成四个阶段：提交与触发、自动验证、人工评审、准入与合并。每个阶段都有明确的组件承担职责。

• GitLab CI/CD：由 .gitlab-ci.yml 定义流水线，MR 一创建或更新就触发 pipeline。它承担的是“机器能判断的部分”——编译是否通过、单元测试是否全绿、静态扫描是否发现阻断级问题、覆盖率是否达标。CI 的结论以 Job 状态和 Artifact 形式回写到 MR 页面。
• Merge Request：整个治理链的“载体”和“信息汇聚点”。它承载 diff、讨论、CI 状态、审批状态、合并检查项。没有 MR，其他组件就没有附着点。
• Code Review：人工判断层。评审者在 diff 行级留下评论、提出修改建议（Suggestion）、标记 Resolve。它处理的是 CI 无法覆盖的问题：设计合理性、命名与可读性、边界条件、安全隐患、是否引入技术债。
• Protected Branch：入口守门人。对 main、release/* 等分支设置“禁止直接 push”“禁止 force push”“仅 Maintainer 可合并”，从机制上杜绝绕过评审的直推。
• Approval Rules：把“需要几个人同意、需要谁同意”写成规则。例如要求至少 2 名审批人、其中 1 名必须是 security-team 成员，且代码所有者（Code Owners）路径匹配时自动指派对应负责人。

二、组件之间的协同关系

这五个组件的关系可以用一句话概括：MR 是舞台，CI 是自动裁判，Review 是人工裁判，Protected Branch 是门锁，Approval Rules 是钥匙的发放规则。 一次典型的合并需要同时满足：pipeline 成功、所有讨论已 Resolve、审批人数与身份满足规则、目标分支保护策略允许合并。任何一项不满足，Merge 按钮就是灰的。

值得注意的是反馈方向并非单向。CI 失败会阻止审批推进；Review 中提出的修改会触发新的 commit，从而重新触发 pipeline；Approval Rules 中若配置了“新提交后重置审批”，则每次 push 都会让已有 approval 失效，迫使评审者重新确认。这种“变更即重置”的设计，正是防止“先审批后偷改”的关键。

三、从“能跑”到“能合”：一次 MR 的实际判断过程

假设某团队在 main 分支上配置了如下策略：Protected Branch 禁止直接 push；Approval Rules 要求至少 2 名审批人，其中 1 名必须是 backend-owners；CI 中 test 与 sast 两个 Job 为阻断项。开发者提交 MR 后，实际会经历这样的判断：

1. MR 创建，pipeline 自动触发。若 test 失败，MR 页面显示红色状态，Merge 按钮不可用，此时无需人工介入即可拦截。
2. CI 通过后，评审者进入 Changes 页逐行评审。若提出 Suggestion，作者可直接在 MR 中 Apply，产生新 commit。
3. 新 commit 触发 pipeline 重跑；若 Approval Rules 勾选了“新提交后重置审批”，此前已获得的 approval 全部失效，需重新审批。
4. 当 pipeline 绿、所有讨论 Resolve、2 名审批人（含 backend-owners 成员）均已 approve，Merge 按钮才变为可用。
5. 合并动作本身仍受 Protected Branch 约束：只有具备合并权限的角色才能执行，且不允许 force push 覆盖历史。

四、组件配置中的关键参数与常见误区

要让这套机制真正生效，几个参数必须显式设置，而不是依赖默认值。

五、协同关系的本质