Passer au contenu principal

Fondamentaux (GitLab)

Gestion des depots Git

GitLab est d'abord une forge Git. La gestion des depots couvre les acces, les branches, les protections, les hooks et les fonctionnalites collaboratives comme les MR et les revues de code.

Acces Git : SSH et HTTP

Deux protocoles sont supportes. SSH est recommande pour les developpeurs : authentification par cle, sans mot de passe. HTTP avec token personnel (PAT) est pratique pour les scripts et la CI. GitLab supporte les cles SSH de type Ed25519 (recommande), ECDSA et RSA (minimum 2048 bits).

# Ajouter une cle SSH
ssh-keygen -t ed25519 -C "user@example.com"
# Copier ~/.ssh/id_ed25519.pub dans GitLab > Preferences > SSH Keys

# Tester la connexion
ssh -T git@gitlab.example.com

Protection des branches

La protection de branche est le mecanisme central de gouvernance du code. Pour chaque branche (ou pattern), on peut :

  • Autoriser le push uniquement aux mainteneurs (ou personne)
  • Interdire le force-push
  • Exiger des pipelines verts avant merge
  • Exiger un nombre minimum d'approbations
  • Definir des code owners comme approbateurs obligatoires

La branche par defaut (historiquement master, maintenant main par defaut sur les nouvelles installations) est protegee automatiquement.

Git LFS

GitLab supporte Git Large File Storage nativement. Les fichiers binaires volumineux (images, videos, archives, modeles ML) sont stockes separement du depot Git et remplacees par des pointeurs. Le stockage LFS peut etre configure sur object storage (S3-compatible) pour eviter de saturer le disque de Gitaly.

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add file.psd
git commit -m "Add LFS-tracked file"

Mirroring

GitLab peut synchroniser un depot en push ou pull depuis/vers un depot distant (GitHub, Bitbucket, autre GitLab). Le mirroring push permet de maintenir un miroir en lecture seule sur GitHub pour la visibilite, tout en travaillant sur GitLab. Le mirroring pull permet d'importer des contributions depuis un repo externe.

Hooks et webhooks

Deux niveaux de hooks :

  • Server-side hooks : scripts executes par Gitaly sur le serveur (pre-receive, update, post-receive). Configures par l'admin dans /var/opt/gitlab/gitaly/custom-hooks/. Utiles pour enforcer des politiques au niveau Git (convention de commit, taille de fichier...).
  • Webhooks : appels HTTP configures dans les parametres du projet ou du groupe. Declenches sur push, MR, issues, pipeline events. Permettent d'integrer GitLab avec des systemes externes.

Sources