1. 课程导入与治理全景

在研发团队规模从十几人扩展到上百人之后，GitLab 往往不再只是一个“放代码的地方”。它同时承载了代码托管、合并请求评审、CI/CD 流水线、制品仓库、议题跟踪、环境部署与安全扫描等职责。当这些能力叠加在一起，权限问题就会从“谁能看这个仓库”演变为“谁能触发生产发布”“谁能绕过保护分支”“谁的令牌可以读取全部子组”这类直接影响交付安全与合规的问题。本课程讨论的GitLab 研发权限与项目治理工程，正是把权限从零散配置升级为可设计、可审计、可演进的工程体系。

一、治理目标：从“能用”到“可控、可查、可演进”

治理工程的目标不是把权限收得越紧越好，而是让正确的角色在正确的边界内获得恰好够用的能力。具体可拆成四个可检验的目标：

• 最小权限：开发者默认不具备直接推送受保护分支的能力，发布动作通过受控流水线完成，而不是依赖个人账号的 Maintainer 权限。
• 职责分离：提交代码的人与批准合并的人不应是同一人；能修改 CI 配置的人与能审批生产部署的人应分属不同角色。
• 可追溯：每一次权限变更、每一次保护分支规则调整、每一次令牌创建，都应能在审计事件中定位到操作者、时间与对象。
• 可演进：当组织从单体仓库拆分为多项目、多子组时，权限模型能够通过继承与模板批量调整，而不是逐仓库手工修改。

二、治理边界：哪些属于本课程，哪些不属于

明确边界可以避免把治理工程做成“什么都管”的万能筐。本课程聚焦于 GitLab 自身的权限与项目结构治理，包括：用户与群组、角色与成员关系、项目可见性、保护分支与保护标签、合并请求审批规则、访问令牌与部署令牌、CI/CD 变量与运行器权限、审计事件与合规检查。以下内容不作为本课程核心：企业级 SSO/IdP 的具体对接实现、Kubernetes RBAC 的细粒度策略、代码本身的业务安全漏洞修复。它们与治理相关，但属于相邻领域，本课程只在接口层面说明如何衔接。

三、核心对象：治理工程操作的真实客体

治理不是抽象概念，它操作的是 GitLab 中一组具体对象。理解这些对象之间的包含与继承关系，是后续所有配置的前提。

• 群组（Group）与子组（Subgroup）：权限继承的骨架。父组授予的成员角色会向下传递，子组可以覆盖但不能削弱父组已授予的更高权限。
• 项目（Project）：权限落地的最小单元，拥有独立的可见性、成员、保护分支与 CI 配置。
• 成员与角色：Guest、Reporter、Developer、Maintainer、Owner 五级，决定能执行的动作集合。
• 保护分支/标签：规定哪些角色可以推送、合并、强制推送，是防止误操作与越权发布的关键闸门。
• 令牌与凭据：个人访问令牌、项目访问令牌、部署令牌、部署密钥，是自动化流程的身份载体，也是泄露风险的高发点。
• 审计事件：记录权限与配置变更的事实来源，是验证治理是否生效的证据链。

这些对象并非孤立存在，而是形成一条从组织到代码的权限传递链。下图展示了核心对象之间的包含、继承与作用关系，可作为后续章节的全局参照。

四、整体实施框架：四个阶段与一条主线

把治理工程落地，可以按四个阶段推进，但阶段之间并非严格串行，而是随组织变化持续迭代。

阶段一：盘点与建模。先回答“现在有什么”。导出群组与项目清单，记录每个项目的可见性、成员角色分布、保护分支规则、令牌数量与最近使用时间。一个常见的教学示例是：某团队有 3 个顶层群组、12 个子组、约 80 个项目，其中 6 个项目为 Public 可见性，23 个项目存在超过 5 个 Maintainer，14 个部署令牌已超过 180 天未轮换。这些数字本身不是结论，而是后续决策的输入。

阶段二：设计目标模型。根据组织架构确定群组层级与命名规范，明确每类角色的标准权限集，定义保护分支策略与审批规则。例如约定：主干分支仅允许 Maintainer 合并，且至少需要 1 名代码所有者批准；生产环境部署只能由受保护的 CI 变量与特定运行器触发。

阶段三：实施与迁移。通过群组继承、成员批量调整、保护规则模板化、令牌轮换等方式把目标模型落到实际对象上。此阶段要特别关注“权限收敛”带来的影响：把某成员从 Maintainer 降为 Developer 之前，需确认其没有依赖直接推送的自动化脚本。

阶段四：审计与持续改进。定期检查审计事件、令牌有效期、保护分支覆盖率与审批规则执行情况，把偏差反馈回设计阶段。治理不是一次性项目，而是随团队演进的常态工作。

五、一个可参考的治理检查起点

在正式进入后续章节前，可以先建立一份最小检查清单，用于快速判断当前 GitLab 实例的治理成熟度。以下字段可根据实际环境填写，作为盘点阶段的直接产出。