4. GitLab项目与群组治理结构设计
当企业从“几个人用 GitLab 管代码”走向“多团队、多产品线、多环境协同”时，最先暴露的问题往往不是功能缺失，而是结构失控：项目散落在个人命名空间下，权限靠逐个加人维护，外包人员能看到核心仓库，归档项目仍可被推送。要解决这些问题，必须把 GitLab 的 Group / Subgroup / Project 三层结构当作企业组织架构在平台上的映射来设计，而不是随手建仓库。
一、三层结构分别承载什么
GitLab 的命名空间本质是一棵树：Group（群组）是顶层容器，通常对应公司、事业部或一条产品线；Subgroup（子群组）对应部门、团队或某个交付单元；Project（项目）才是真正存放仓库、Issue、CI/CD、制品的地方。关键点在于：权限和可见性沿这棵树向下继承。给一个 Group 添加成员，其下所有 Subgroup 和 Project 都会继承该成员的角色；把 Project 设为 Private，则只有继承链上有权限的人才能访问。因此结构设计的第一原则是：先定组织边界，再定权限边界，最后才落项目。
一个常见的误区是按“技术栈”建群组，比如把所有 Java 项目放一起、所有前端放一起。这会导致权限无法按团队收敛——前端团队要访问的仓库散落在多个群组里。正确做法是按“谁负责、谁授权、谁审计”来划分群组，技术栈用标签（Label）或项目主题（Topic）表达，而不是用命名空间表达。
二、权限模型：角色与继承
GitLab 的成员角色从低到高为 Guest、Reporter、Developer、Maintainer、Owner。企业治理中最容易出错的是把 Developer 当成“普通开发”随意授予，实际上 Developer 可以推送代码、触发流水线、创建分支，但不能改保护分支规则、不能改项目可见性、不能删项目；Maintainer 才能管理保护分支和 Webhook；Owner 才能转移项目、删除群组。建议的收敛策略是：
- 普通研发：在所属 Subgroup 授予 Developer，不直接加到 Project，避免人员流动时漏删。
- Tech Lead / 模块负责人：在 Subgroup 授予 Maintainer，负责保护分支与合并策略。
- 测试、产品、运维只读：授予 Reporter，可看代码、提 Issue、看流水线，但不能推送。
- 外包与外部协作：单独建 Subgroup，授予 Guest 或 Reporter，并配合项目可见性为 Private。
- 群组 Owner 只保留给平台管理员或极少数治理负责人，避免权限泛滥。
继承带来的一个实用技巧是：把“共享角色”放在上层，把“差异角色”放在下层。例如整个研发中心在顶层 Group 授予 Reporter 给所有产品经理，某个产品线的核心仓库再单独给该产品线开发授予 Developer。这样新增项目时无需重复授权，权限自动继承。
三、可见性策略：Private / Internal / Public
可见性决定“谁能看到”，与角色决定“能做什么”是两个维度。企业环境通常建议：
- Private：仅成员可见，用于核心业务代码、含密钥或客户数据的仓库，是默认选择。
- Internal：登录用户可见，适合内部工具、文档、公共组件库，方便跨团队检索复用。
- Public：匿名可见，企业内一般禁用，除非是开源项目或对外 SDK。
需要特别注意的是：子群组和项目的可见性不能比父群组更宽松。如果父 Group 是 Private，子项目无法设为 Internal。因此顶层群组一旦定为 Private，整棵树都被约束在私有范围内，这通常是企业最安全的起点。若确实需要部分内部共享，可在顶层下单独建一个 Internal 的 Subgroup 承载公共组件。
四、结构设计示例
下面给出一个可直接参考的层级设计，假设企业有两条产品线和一个平台团队：
company (Group, Private)
├── platform (Subgroup) # 平台/基础架构团队
│ ├── ci-templates (Project, Internal)
│ ├── deploy-tools (Project, Private)
│ └── observability (Project, Private)
├── product-a (Subgroup) # 产品线 A
│ ├── core-service (Project, Private)
│ ├── web-console (Project, Private)
│ └── shared-lib (Project, Internal)
├── product-b (Subgroup) # 产品线 B
│ ├── gateway (Project, Private)
│ └── mobile-app (Project, Private)
└── external (Subgroup) # 外包/合作方隔离区
└── vendor-integration (Project, Private)
对应的权限分配：平台团队在 platform 授予 Maintainer；产品线 A 研发在 product-a 授予 Developer；产品经理在整个 company 授予 Reporter；外包人员在 external 授予 Reporter，且该 Subgroup 与产品线之间没有继承关系，天然隔离。这样，新增一个 product-a 下的仓库时，产品线 A 的研发自动获得 Developer，无需人工干预。
五、落地时的检查要点
结构设计完成后，建议用以下几条做一次自检：第一，是否所有项目都挂在某个 Subgroup 下，而不是散落在个人命名空间；第二，是否所有成员都通过群组授权，而不是逐个项目加人；第三，核心仓库是否全部为 Private，Internal 是否只用于确实需要跨团队共享的组件；第四，外包与外部协作是否放在独立 Subgroup，与产品线之间没有继承路径；第五，Owner 数量是否收敛，通常每个群组不超过 2～3 人。满足这五条，后续的代码评审、分支保护、CI/CD 权限和审计才能在一个稳定的结构上展开，而不是每次都要临时补权限、查泄露。