gitlab默认角色权限清单

GitLab 默认角色权限是分层、递增的，核心围绕三类能力展开：

• 仓库代码（Repository）
• 协作流程（Issue / MR / CI）
• 项目与权限管理（Settings / Members）

---

2.GitLab 默认角色一览（官方内建）
2.1.角色层级（从低到高）

1. Guest
2. Reporter
3. Developer
4. Maintainer
5. Owner（仅 Group 层级存在）

---

3.核心权限矩阵（生产最常用视角）

3.1.代码仓库相关（最容易踩坑）

角色	查看代码	clone / pull	push	创建分支
Guest	❌	❌	❌	❌
Reporter	✅	✅	❌	❌
Developer	✅	✅	✅	✅
Maintainer	✅	✅	✅	✅
Owner	✅	✅	✅	✅

👉 结论记忆法：

• clone 的门槛 = Reporter
• push 的门槛 = Developer

---

3.2.Issue / MR / 协作权限

角色	看 Issue	提 Issue	提 MR	Approve MR
Guest	✅	❌	❌	❌
Reporter	✅	❌	❌	❌
Developer	✅	✅	✅	❌
Maintainer	✅	✅	✅	✅
Owner	✅	✅	✅	✅

---

3.3.CI / Pipeline 权限

角色	查看 Pipeline	运行 Pipeline	修改 CI
Guest	❌	❌	❌
Reporter	✅	❌	❌
Developer	✅	✅	✅
Maintainer	✅	✅	✅
Owner	✅	✅	✅

---

3.4.项目与权限管理（管理类能力）

角色	管理成员	改项目设置	删除项目
Guest	❌	❌	❌
Reporter	❌	❌	❌
Developer	❌	❌	❌
Maintainer	✅	✅	❌
Owner	✅	✅	✅

---

4.一���关键但常被忽略的事实
4.1.API ≠ Git 权限

• Guest / Reporter 可以通过 API 看到项目信息
• 但 Git clone/pull 是单独的 Repository 权限判断

这正是你之前场景中：

API 能访问，但 git clone 报 “project not found or no permission”
的根本原因之一。

---

5.前瞻性运维建议（非常实用）
5.1.权限分配最佳实践

• CI / 只读拉代码 → Reporter
• 日常开发 → Developer
• 负责人 / 仓库治理 → Maintainer
• 不要给 Guest 做任何自动化 clone

5.2.Token 使用原则

• Token 继承的是“用户角色”权限
• 给 Guest 用户发 PAT，clone 永远失败
• 想 clone，最低 Reporter + read_repository

---

6.一句话终极总结
6.1.

Guest 只能“看项目壳子”，Reporter 才能“拉代码”，Developer 才能“写代码”。

如果你愿意，我可以帮你：

• 按 最小权限原则 设计一套 GitLab 用户/Token 规范
• 或画一张 Group → Subgroup → Project 权限继承 Mermaid 图，把所有坑一次性扫干净