Permissions and Access Governance in GitLab
Access is role-based across five levels -- Guest, Reporter, Developer, Maintainer, and Owner -- applied at the group or project level, with permissions inheriting down from group to subgroup to project unless explicitly overridden. Developers can push to unprotected branches and open merge requests, while Maintainers can merge, manage CI/CD variables, and configure protected branches -- a distinction that matters for keeping main/production branches genuinely protected.
Practical Details
Protected branches (typically main/production) can require merge request approvals from specific people or groups, block direct pushes, and require passing CI/CD pipelines before a merge is allowed -- this is configured per-project and is the primary technical control for enforcing code review. GitLab Ultimate adds more granular controls like custom roles (beyond the five defaults) and compliance frameworks for regulated environments.
Actionable Considerations
- Protect your main/production branches and require merge request approval plus passing CI before allowing a merge -- don't rely on team discipline alone
- Set permissions at the group level where possible rather than configuring each project individually, so new projects inherit sensible defaults
- Use custom roles (Ultimate tier) if the five default roles don't map cleanly to how your team actually splits responsibilities