Git权限需角色与保护机制双重生效：Developer不能直接push到受保护的main分支，仅Maintainer及以上可合并MR；角色权限向上兼容，但保护分支、CODEOWNERS等规则可覆盖角色权限。
Git权限按角色分级管理，本质不是“设个角色就完事”，而是角色 + 保护机制双重生效。直接给Developer角色，不代表能往main分支push——如果该分支被设为保护分支，那Developer依然会被拒绝，必须由Maintainer或更高权限者批准合并。
GitLab里Guest/Reporter/Developer/Maintainer/Owner到底能干啥
这五个内置角色是向上兼容的：一个Maintainer自动拥有Developer、Reporter、Guest全部能力，但反向不成立。关键差异集中在三件事上：
-
push目标：只有Developer及以上能push到非保护分支；保护分支（如main）只允许Maintainer及以上直接push或通过MR合并 -
merge权限：只有Maintainer和Owner能批准MR；Developer可以提MR，但不能approve - 管理操作：
Owner能删项目、改群组成员；Maintainer能加人、设保护分支、调CI设置；Developer连“添加协作者”按钮都看不到
注意：Guest角色必须被手动加入项目/群组才生效；裸登录用户即使能浏览Internal项目，也不等于有Guest权限——他不能评论Issue、不能创建MR。
保护分支和CODEOWNERS会覆盖角色权限
角色决定“能不能操作”，而保护分支、CODEOWNERS、.gitlab-ci.yml里的rules等是“额外闸门”。比如：
- 把
release/*设为保护分支，并要求2人approval → 即使你是Owner，也不能绕过审批直接push - 在
CODEOWNERS中指定src/backend/** @backend-lead→ 所有涉及该路径的MR，必须由@backend-leadapprove，不管提交者是什么角色 - CI配置里写
rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'→ 只有MR触发的流水线才跑，Developer手动push到非保护分支不会触发敏感构建步骤
这类细粒度控制不依赖角色，而是独立开关，必须单独配置，否则角色权限会“过度放行”。
自建Git平台（Gitolite/Gitea）怎么实现更细的分支级权限
GitLab原生不支持“只让某人push到dev但禁止push到feature/*”，这时得换工具：
- Gitolite用
conf/gitolite.conf声明式定义：repo myapp\n RW+ dev$ = @dev-team\n R feature/.* = @interns→ 实习生只能读所有feature/分支，开发团队可对dev分支强推 - Gitea靠
TeamUnit结构体控制单元权限：一个团队可被授予Code单元的Read权限，同时在Issues单元设为Write，实现“能提Bug但不能看代码” - GitPuk支持
.gitpuk-permissions文件动态规则：match: "refs/heads/release-*"下限定allowed_groups: ["qa-team"]和required_approvals: 2，比GitLab保护分支更灵活
这些方案的共同点是：权限决策发生在服务端pre-receive hook阶段，不依赖客户端角色缓存，也规避了GitLab里“加了角色却忘了开保护分支”的典型疏漏。
真正卡住权限的从来不是角色名本身，而是保护分支是否开启、CODEOWNERS是否覆盖、以及你用的平台是否支持分支正则匹配。很多人配完Maintainer还收不到MR通知，其实是没打开项目设置里的Notifications开关——这个和角色无关，但直接影响协作流。
