GitLab的RBAC模型适合中大型团队，因其权限绑定Project/Group两级，角色固定且与企业架构天然对齐，支持批量赋权；但Maintainer权限过高需慎用，Protected Branches须分开配置合并与推送权限。
Git 服务商权限模型差异确实大，不是“功能差不多”的问题，而是底层设计哲学不同——选错会导致流程卡死、审计翻车或权限失控。
GitLab 的 RBAC 权限模型为什么适合中大型团队
GitLab 把权限绑在 Project 和 Group 两级，角色固定（Guest/Reporter/Developer/Maintainer/Owner），每个角色对代码、议题、CI、Wiki 的操作权限都明确定义。这种模型和企业组织架构天然对齐，也方便做批量赋权。
实操建议：
- 不要用
Maintainer角色管理所有项目——它能删仓库、改保护分支、接管 CI 变量，风险过高；关键项目应拆出Developer+Approver（通过合并请求审批规则模拟）组合 - 启用
Protected Branches时，务必为Allowed to merge和Allowed to push分开设置；默认两者都勾选等于开放直推，违背评审前提 - 社区版不支持
Scoped Labels或Role-based issue filtering，如果审计要求“某部门只能看到本部门 Issue”，必须升企业版或加外部网关层
Gerrit 的 Label 权限体系如何防止“假评审”
Gerrit 不是靠角色，而是靠 Label 打分机制控制代码落地。比如 Code-Review 和 Verified 是两个独立标签，可分别授权给不同人群：开发自评 Code-Review +1，QA 给 Verified +1，架构师才有 Submit 权限。这避免了“一个人既写又审还合入”的典型漏洞。
常见错误现象：
- 把
Submit权限直接给到Developers组 → 失去审查强制性，等同于退化成普通 Git - 没配置
submit-type = Fast Forward Only→ 合并后产生多余 merge commit，破坏线性历史，影响git bisect定位 - 忽略
Max. number of votes限制 → 某人反复打 +2，掩盖其他评审意见，实际只算一次
GitHub Enterprise Server 的权限陷阱在哪
GitHub 的权限粒度最粗，Admin/Write/Read/Triage 四档，且不支持按分支设推送权限（仅靠 branch protection rules 限制合入，但不能禁 push）。这意味着：只要你是 Write，就能 git push --force 到任何非保护分支。
使用场景提醒：
- 政企单位若要求“禁止任何 force-push”，仅靠 GitHub 原生能力做不到，必须配合 pre-receive hook（需 GHES 自托管+管理员权限）或外挂 Gitleaks/GitGuardian 等扫描工具拦截
-
Triage角色看似安全，但它能关闭 Issue、编辑标签、分配 Assignee —— 若未同步清理 Jira 或禅道的双向同步权限，可能造成需求状态失真 - Secret scanning 和 Dependabot alerts 默认只对
Admin发通知，Developer级别看不到高危依赖告警，需手动开启Repository security advisories共享范围
权限模型选型时最容易被忽略的点
不是“谁能看代码”，而是“谁能在什么条件下触发什么动作”。比如：
- Gerrit 的
submit操作会自动关闭关联的 Change，但 GitLab 的Merge不会自动关 Issue，除非显式写Closes #123—— 这直接影响审计链路完整性 - GitLab CI 变量默认对
Developer不可见，但 GitHub Actions secrets 对Write用户完全可见（除非用 environment-level secrets 并绑定 approval），敏感凭证泄漏风险差一个数量级 - 所有平台都支持 LDAP/AD 同步，但同步后用户组映射是否实时？Gerrit 需重启 daemon，GitLab 有
ldap_sync命令但默认不自动跑，GitHub 则依赖 SCIM —— 这决定了离职人员权限回收时效是否满足等保 2.0 要求
