4. 项目可见性与访问级别
在 GitLab 中，一个项目“谁能看到”和“谁能做什么”是两个独立但必须配合使用的维度。前者由项目可见性（Visibility）决定，回答“这个项目对谁可见”；后者由成员访问级别（Access Level）决定，回答“进入项目后能执行哪些操作”。很多权限事故并非角色分配错误，而是可见性设置与角色能力边界没有对齐——例如把本应仅限团队内部的项目设为 Internal，导致全公司可读；或给外部协作者分配了 Developer 而非 Reporter，使其获得了推送代码的能力。本节先厘清可见性三档，再逐级拆解 Guest 到 Owner 的能力边界，最后给出可见性与角色的组合判断方法。
一、项目可见性三档：Private、Internal、Public
GitLab 项目可见性分为三档，其差异体现在“未登录用户”“已登录用户”“项目成员”三类主体的访问结果上：
- Private（私有）：只有被显式添加为项目成员的用户才能访问。未登录用户、已登录但非成员的用户均无法看到项目页面、仓库、Issue、Merge Request 等任何内容。这是企业内部项目最常用的默认档位。
- Internal（内部）：任何已登录的 GitLab 用户都可以访问该项目（通常为只读或按角色受限）。未登录用户不可见。它适合“全公司可读、但不对互联网公开”的场景，例如内部规范库、公共工具仓库。
- Public（公开）：任何人（包括未登录的匿名用户）都可以访问项目页面与仓库内容。适合开源项目或对外宣传的示例仓库。
需要特别强调：Internal 的“内部”范围由 GitLab 实例的登录用户集合决定。如果实例允许自助注册或对接了宽松的 SSO，Internal 的实际暴露面可能远大于预期。因此在合规敏感环境中，Internal 不应被当作“安全档位”使用，而应视为“半公开”。
二、Guest 到 Owner：五级角色的能力边界
GitLab 成员访问级别从低到高为 Guest、Reporter、Developer、Maintainer、Owner。级别是累加的：高等级包含低等级的全部能力。下面按“读、写、管”三个维度梳理关键边界。
| 角色 | 代码读取 | 代码推送 | Issue/MR 操作 | 项目设置 | 成员管理 |
|---|---|---|---|---|---|
| Guest | 私有项目不可读；Internal/Public 可读 | 否 | 可提 Issue、可评论，不能看私有项目代码 | 否 | 否 |
| Reporter | 可读代码与 CI 日志 | 否 | 可提 Issue/MR、可评论 | 否 | 否 |
| Developer | 可读 | 可推送到非保护分支 | 可创建/合并 MR（受保护分支限制） | 部分（如 CI 变量） | 否 |
| Maintainer | 可读 | 可推送、可管理保护分支 | 可合并、可管理 MR 设置 | 可改项目设置、Webhook、CI/CD | 可添加低级别成员 |
| Owner | 可读 | 可推送 | 全部 | 全部，含删除项目、转移项目 | 可管理所有成员，含 Owner |
几个容易踩坑的边界点：
- Guest 在私有项目中看不到代码。Guest 的典型用途是让外部人员参与 Issue 讨论，而不是读代码。若需要外部人员读代码，至少给 Reporter。
- Reporter 不能推送代码，但可以读取 CI 日志。CI 日志中可能包含环境变量、部署地址等敏感信息，因此给 Reporter 前要评估日志脱敏情况。
- Developer 能推送非保护分支，但不能直接推保护分支。保护分支（如 main、release/*）的推送与合并权限由 Maintainer 控制。这是“能写代码”与“能改主干”之间的关键分界线。
- Maintainer 能改 CI/CD 配置与 Webhook，这意味着其可以间接影响构建产物与外部系统，权限风险高于普通开发者。
- Owner 可删除或转移项目，属于最高风险操作，通常只授予项目负责人或平台管理员。
三、可见性与角色的组合判断
实际授权时，应先确定可见性，再选择角色，最后检查“可见性是否放大了角色的暴露面”。例如：一个 Internal 项目，即使只给某人 Guest，该用户仍能看到项目存在、Issue 标题与评论；若项目是 Private，则非成员完全不可见。因此对于含敏感信息的项目，应优先收紧可见性，而不是仅靠降低角色来兜底。
下面这张图把三档可见性与五级角色的关系放在同一张“授权矩阵”中，帮助快速判断“某类主体在某个可见性下、某个角色上，实际能触达什么”。
四、实操：如何设置与复核
在项目页面进入 Settings → General → Visibility, project features, permissions，可修改项目可见性。修改为更宽松的档位（如 Private → Internal）会立即扩大可见范围，需谨慎操作；从宽松改为严格（如 Public → Private）会立即收回非成员访问，但已克隆的本地副本无法收回。
成员角色在 Settings → Members 中管理。添加成员时，GitLab 会显示可选角色下拉框；Owner 可授予 Owner，Maintainer 只能授予不超过 Maintainer 的角色。建议遵循最小权限原则：外部协作者默认 Guest 或 Reporter，内部开发者默认 Developer，仅项目负责人给 Maintainer，Owner 数量控制在 1～2 人。
总结来看，可见性解决“门开多大”，角色解决“进门后能走多远”。两者必须一起设计：先按数据敏感度选可见性，再按职责选最小角色，最后用定期复核兜底。掌握这张授权矩阵，就能在协作效率与权限安全之间取得可控的平衡。