Passer au contenu principal

Fondamentaux (GitLab)

Projets, groupes et namespaces

GitLab organise le contenu en namespaces : chaque utilisateur et chaque groupe dispose d'un namespace. Les projets vivent dans un namespace. La hierarchie peut etre profonde (groupes et sous-groupes imbriques), ce qui permet de modeliser des organisations complexes.

Groupes et sous-groupes

Un groupe regroupe des projets et des membres. Les sous-groupes permettent d'aligner la structure GitLab sur l'organigramme : acme / backend / api, acme / frontend / dashboard. Les permissions, les runners CI, les variables et les politiques de securite se configurent au niveau du groupe et se propagent aux sous-groupes et projets.

Bonne pratique : eviter une hierarchie trop profonde (plus de 3 niveaux). L'heritage de permissions devient difficile a raisonner et les URLs deviennent longues.

Projets

Un projet contient : un depot Git, des issues, des MR, un wiki, des pipelines CI/CD, un registre de conteneurs, des packages. La visibilite d'un projet peut etre publique, interne (tous les utilisateurs connectes) ou privee.

Projets forkes : GitLab supporte le fork natif et maintient le lien entre le projet amont et le fork. Les MR peuvent etre ouvertes du fork vers le projet amont. Le fork namespace est configurable dans les parametres du projet.

Namespace et chemins

Chaque ressource GitLab a un chemin unique : https://gitlab.example.com/group/subgroup/project. Ce chemin est utilise pour les URL Git (SSH et HTTP), les webhooks, l'API. Renommer un groupe ou un projet change son chemin et cree une redirection automatique, mais les liens hardcodes dans les scripts externes doivent etre mis a jour.

Transfert de projet

Un projet peut etre transfere d'un namespace a un autre. GitLab cree une redirection automatique sur l'ancien chemin, mais celle-ci peut etre supprimee. Les CI/CD runners attaches au projet restent associes. Les variables de groupe ne sont pas heritees automatiquement apres transfert si le projet change de groupe.

Archivage et suppression

L'archivage rend un projet en lecture seule sans le supprimer. La suppression est par defaut differee de 7 jours (configurable par l'admin). En EE, la deletion d'un groupe peut etre soumise a une periode de grace egalement.

Sources