Groups, subgroups et gestion des acces

Hierarchie des groupes

GitLab organise les projets en groupes et sous-groupes :

# Exemple de hierarchie
company/                    # Groupe racine
  frontend/                 # Sous-groupe
    webapp/                 # Projet
    mobile-app/             # Projet
  backend/                  # Sous-groupe
    api/                    # Projet
    workers/                # Projet
  devops/                   # Sous-groupe
    infrastructure/         # Projet
    deploy-scripts/         # Projet

Niveaux d'acces

Heritage des permissions

# Les permissions sont heritees du groupe parent
# Un Developer dans company/ est Developer dans tous les sous-groupes
# On peut augmenter (mais pas reduire) le role dans un sous-groupe

# Creer un groupe via l'API
curl --request POST \
  --header "PRIVATE-TOKEN: $TOKEN" \
  --data "name=Backend&path=backend&parent_id=42" \
  "https://gitlab.example.com/api/v4/groups"

# Ajouter un membre a un groupe
curl --request POST \
  --header "PRIVATE-TOKEN: $TOKEN" \
  --data "user_id=15&access_level=30" \
  "https://gitlab.example.com/api/v4/groups/42/members"

Branches protegees et merge request approvals

# Proteger la branche main
# Settings > Repository > Protected Branches
# - Allowed to merge: Maintainers
# - Allowed to push: No one
# - Require approval: 2 reviewers

# Regles d'approbation
# Settings > Merge Requests > Approval rules
# - Minimum approvals: 2
# - Eligible approvers: @team-leads
# - Code owners approval: Required

CODEOWNERS

# .gitlab/CODEOWNERS
# Chaque section definit qui doit approuver les modifications

# Frontend
frontend/       @frontend-team
*.tsx           @frontend-team
*.css           @frontend-team

# Backend
backend/        @backend-team
*.py            @backend-team

# DevOps / Infrastructure
Dockerfile      @devops-team
.gitlab-ci.yml  @devops-team
terraform/      @devops-team