3. Groups, Projects, & Namespaces

Organization is the backbone of efficient development. While some platforms restrict you to a flat organization/repository structure, GitLab offers hierarchical Groups, Subgroups, and Projects, providing fine-grained access control and structural clarity.

Understanding Namespaces

In GitLab, a Namespace is a unique path in the URL that holds projects or groups. There are two primary types of namespaces:

1. User Namespaces: Your personal space (e.g., `gitlab.com/john-doe/`). Projects created here are owned and managed by you.
2. Group Namespaces: Collaborative spaces created for organizations, teams, or departments (e.g., `gitlab.com/acme-corp/`).

Groups and Subgroups

Unlike GitHub, where an Organization only contains repositories directly, GitLab allows you to create Subgroups inside a Group. This allows you to mirror your actual corporate hierarchy:

acme-corp/                  <-- Main Corporate Group
├── engineering/            <-- Subgroup for Eng Department
│   ├── backend-api/        <-- Project (Repository)
│   └── frontend-spa/       <-- Project (Repository)
├── marketing/              <-- Subgroup for Marketing Department
│   └── public-website/     <-- Project (Repository)
└── finance/                <-- Subgroup for Finance Department
    └── invoicing-tool/     <-- Project (Repository)

Visibility Levels

When creating groups or projects, you can select one of three access visibility levels:

Inviting Users and User Roles

To grant permissions to users in a project or group, GitLab uses a role-based access control (RBAC) model with predefined tiers:

• Guest: Can create issues and post comments, but cannot view repository files.
• Reporter: Can view code, download assets, and manage issues. Ideal for product managers and testers.
• Developer: Full code access. Can push to non-protected branches, create merge requests, and execute pipelines.
• Maintainer: Admin permissions for the project. Can configure CI/CD settings, push to protected branches, and edit repository files.
• Owner: Complete control over the group or project namespace (e.g., changing visibility, removing the project).