GitLab

À quoi ça sert

Comme GitHub, GitLab héberge tes dépôts Git à distance et ajoute par-dessus tout ce qui sert au travail en équipe. La différence d'identité tient en un slogan : GitLab se présente comme une plateforme DevOps unifiée qui couvre tout le cycle, de l'idée au déploiement et à la supervision :

• Hébergement de tes projets (privés ou publics).
• Merge Requests (MR) : l'équivalent des Pull Requests, avec le même esprit (proposer, discuter, fusionner).
• Issues et planning intégré (Kanban, tableaux, milestones).
• GitLab CI/CD : pipelines déclarés dans un fichier .gitlab-ci.yml à la racine, lancés à chaque push.
• Container Registry et Package Registry pour stocker tes images Docker et tes paquets, inclus de base.
• Pages : même principe que GitHub Pages pour publier un site statique.

Un exemple d'usage

Tu travailles sur un projet d'IA en équipe. Chacun bosse sur sa branche, propose ses changements via une Merge Request, les autres relisent et commentent, et une fois validée, la MR est fusionnée dans main. À chaque MR, GitLab CI lance automatiquement les tests pour vérifier que rien ne casse.

Le workflow type, identique à Git d'un service à l'autre :

# Récupérer la dernière version
git pull origin main

# Créer une branche pour ta feature
git checkout -b feat/ma-fonctionnalite

# Coder, puis committer
git add .
git commit -m "Ajoute la fonctionnalité X"

# Pousser et ouvrir une MR
git push origin feat/ma-fonctionnalite

Au push, GitLab affiche dans la console l'URL directe pour créer la MR (pratique : pas besoin de retourner sur le site). Tu décris ton changement, tu attends la review, et la MR est fusionnée.

How-to : configurer GitLab

GitLab.com est un service en ligne, donc rien à installer côté plateforme. Tu as juste besoin d'un compte web et de Git localement. La procédure est très proche de GitHub : les commandes Git sont strictement les mêmes, seuls les noms d'écrans et les URLs changent.

1. Créer un compte GitLab

   1. Va sur gitlab.com/users/sign_up.
   2. Choisis un username stable (il apparaîtra dans toutes tes URLs gitlab.com/<username>/...).
   3. Utilise une adresse e-mail durable.
   4. Active la vérification en deux étapes dès que possible (Settings → Account → Two-Factor Authentication).
   2FA et CI

   Comme GitHub, GitLab pousse fortement vers la 2FA obligatoire. Active-la à la création avec une appli type Authy / Google Authenticator. Pour les push depuis ton PC, tu utiliseras des clés SSH (étape 5) ou un Personal Access Token — la 2FA ne te dérange pas.

2. Créer ton premier projet

   Sur GitLab, on parle de Project (équivalent du Repository de GitHub).

   1. Clique sur « New project » en haut à droite, puis « Create blank project ».
   2. Donne un nom au projet (ex. devia-tp1).
   3. Choisis la visibility level : Private, Internal (visible à tous les utilisateurs connectés du serveur) ou Public. Internal est une nuance que GitHub n'a pas — utile en entreprise / école.
   4. Coche « Initialize repository with a README ».
   5. Optionnel : ajoute un .gitignore Python.
   6. Clique sur « Create project ».

3. Installer Git sur ton PC

   Étape strictement identique à GitHub — Git est un outil unique, indépendant du service distant. Si Git est déjà installé pour GitHub, passe à l'étape suivante.

   bash Copier

   # macOS
   brew install git
   
   # Linux (Debian / Ubuntu)
   sudo apt install git
   
   # Windows
   winget install --id Git.Git -e
   
   # Vérifier
   git --version

4. Configurer ton identité Git

   Aussi indépendant du service. Si déjà fait pour GitHub, c'est OK pour GitLab.

   bash Copier

   git config --global user.name "Ton Prénom"
   git config --global user.email "ton-email@example.fr"
   git config --global init.defaultBranch main

   E-mail privé GitLab

   Pour ne pas exposer ton e-mail dans les commits, GitLab fournit aussi un alias du type 123456-username@users.noreply.gitlab.com. Trouve-le dans Settings → Profile → Public email / commit email.

5. Authentifier ton PC auprès de GitLab (clé SSH)

   Même principe que GitHub. Si tu as déjà une paire de clés id_ed25519, tu peux la réutiliser : une clé SSH n'est pas attachée à un service en particulier.

   bash Copier

   # Générer une paire de clés (si tu n'en as pas déjà une)
   ssh-keygen -t ed25519 -C "ton-email@example.fr"
   
   # Afficher la clé publique
   cat ~/.ssh/id_ed25519.pub

   Sur GitLab : avatar (en haut à droite) → Edit profile → SSH Keys, colle la clé publique, donne-lui un titre. Vérifie :

   bash Copier

   ssh -T git@gitlab.com
   # → "Welcome to GitLab, @username!"

6. Cloner et travailler avec un projet

   Sur la page de ton projet GitLab, clique Clone → Clone with SSH.

   bash Copier

   git clone git@gitlab.com:<username>/<projet>.git
   cd <projet>
   
   # Modifier un fichier...
   git status
   git add .
   git commit -m "Mon premier commit"
   git push

   Au premier push sur une nouvelle branche, GitLab te renvoie dans la console une URL directe pour ouvrir la Merge Request. C'est un petit confort spécifique à GitLab qu'on apprécie vite.

7. Configurer VS Code avec GitLab

   VS Code gère Git nativement. Pour bien intégrer GitLab (MR, issues, pipelines) sans quitter l'éditeur :

   1. Installe GitLab Workflow (GitLab.gitlab-workflow) — extension officielle qui ajoute la gestion des MRs, issues, pipelines et snippets directement dans VS Code.
   2. Installe GitLens (eamodio.gitlens) — agnostique du service, affiche qui a écrit chaque ligne et l'historique.
   3. Connecte ton compte GitLab via un Personal Access Token (Settings → Access Tokens → cocher api et read_user). VS Code te demandera ce token au premier démarrage de l'extension.

8. Bonus : un pipeline GitLab CI minimal

   Là où GitHub utilise .github/workflows/<nom>.yml, GitLab utilise un seul fichier .gitlab-ci.yml à la racine du dépôt :

   yaml Copier

   stages:
     - test
   
   test:python:
     stage: test
     image: python:3.12
     script:
       - pip install -r requirements.txt
       - pytest

   Pousse ce fichier, et GitLab lance automatiquement le pipeline. Le résultat apparaît sur la page de ta MR (badge ✓ ou ✗) et dans l'onglet Build → Pipelines.

   Modèle mental

   Un job GitLab CI tourne dans une image Docker que tu choisis (image: python:3.12), exécute une liste de commandes (script:), et est regroupé dans un stage. Les stages s'enchaînent en série, les jobs d'un même stage tournent en parallèle. C'est l'équivalent direct des jobs: de GitHub Actions, avec un vocabulaire un peu différent.

GitLab vs GitHub : que choisir et pourquoi

Les deux services rendent le même service de base — héberger du code Git, faire des revues de code, lancer des pipelines CI/CD. Les différences sont surtout d'identité, de périmètre et d'écosystème.

Le vocabulaire qui change

• Pull Request (GitHub) → Merge Request (GitLab) — même concept, nom différent. Tu verras parfois les deux abrégés en « MR » ou « PR » dans la même conversation.
• Repository (GitHub) → Project (GitLab) — c'est ton dépôt + ses issues + ses pipelines + son wiki, vu comme un tout.
• Organization (GitHub) → Group (GitLab) — un espace partagé qui regroupe plusieurs projets.
• .github/workflows/*.yml (GitHub Actions) → .gitlab-ci.yml (GitLab CI) — un seul fichier à la racine côté GitLab, un par workflow côté GitHub.
• Branch protection rules (GitHub) → Protected branches (GitLab) — mêmes garde-fous, UI différente.

Forces de chaque côté

Faiblesses respectives

• GitHub est moins « intégré » : pour faire l'équivalent de ce que GitLab fait nativement (container registry, security scan, monitoring), tu vas dépendre d'intégrations tierces. Pas auto-hébergeable gratuitement (GitHub Enterprise Server est payant).
• GitLab a une UI parfois jugée moins fluide (lente sur certaines pages), une communauté plus petite donc moins de projets open source visibles, et moins de notoriété pour un portfolio personnel.

Comment choisir, selon le contexte

• Projet open source / portfolio / contribuer aux autres → GitHub. C'est là que la communauté est, c'est ce qu'un recruteur regardera.
• Stage / job en entreprise DevOps mature → GitLab est très répandu, notamment en Europe et dans les structures qui veulent un outillage intégré.
• Auto-hébergement (école, association, boîte sensible à la souveraineté) → GitLab CE sans hésiter — gratuit, open source, complet.
• Formation / cours → l'un ou l'autre selon ce qu'utilise l'école. Les compétences Git restent transférables à 100 %.
• En vrai, beaucoup de devs ont les deux : GitHub pour l'open source perso, GitLab pour le travail.

Aide-mémoire Git

Les commandes Git sont strictement les mêmes que pour GitHub : Git est l'outil local, la plateforme distante (GitLab, GitHub, Bitbucket…) ne change rien.

# Démarrer / récupérer
git init                       # nouveau dépôt local
git clone <url>                # cloner un dépôt distant

# Cycle de base
git status
git add <fichier>              # stage un fichier
git add .                      # tout
git commit -m "message"
git push
git pull

# Branches
git branch                     # lister
git checkout -b <nom>          # créer + basculer
git switch <nom>               # basculer (équivalent moderne)
git merge <nom>                # fusionner dans la branche actuelle

# Inspecter
git log --oneline --graph
git diff
git blame <fichier>

# Remotes (utile si tu pousses sur plusieurs services)
git remote -v
git remote add gitlab git@gitlab.com:user/repo.git
git push gitlab main

Pour aller plus loin

• Documentation GitLab : docs.gitlab.com
• Tutoriels officiels GitLab : docs.gitlab.com/tutorials
• GitLab CI/CD : docs.gitlab.com/ci
• Pro Git (livre gratuit) : git-scm.com/book/fr
• Fiche jumelle sur ce site : GitHub.