# GitLab : qu'est-ce que c'est et comment travailler avec Git : clone, push, merge request, CI/CD

URL: https://skillaria.top/fr/guides/git/qu-est-ce-que-gitlab

GitLab est une plateforme web qui héberge des dépôts Git et sert à la collaboration : code, merge requests, tâches et CI/CD intégré au même endroit. On peut l'utiliser sur le cloud gitlab.com ou sur le serveur propre d'une entreprise, et le code s'envoie et se récupère avec les commandes Git habituelles : clone, push et pull.

## Qu'est-ce que GitLab

GitLab est une plateforme qui héberge les dépôts Git et organise autour d'eux le travail d'équipe : consultation du code, merge requests (demandes de fusion), tâches, wiki, registre de conteneurs et CI/CD intégré. En résumé, GitLab est « GitHub avec sa propre chaîne de construction et la possibilité de tout installer sur son propre serveur ». De nombreuses entreprises, en France comme ailleurs, conservent leur code dans un GitLab déployé sur leur réseau interne.

Le projet a débuté en 2011 comme application libre d'hébergement de code ; l'entreprise GitLab Inc. s'est construite autour de lui. La plateforme existe en deux éditions : la Community Edition, version ouverte que l'on peut installer gratuitement sur son serveur, et la Enterprise Edition, avec des fonctions payantes. Sur le service cloud gitlab.com, les offres s'appellent Free, Premium et Ultimate.

Il ne faut pas confondre les notions. Git est un système de gestion de versions, c'est-à-dire un programme sur votre ordinateur. GitLab est un service qui conserve une copie distante du dépôt et ajoute une interface et des outils pour l'équipe. On ne peut pas travailler avec GitLab sans Git, alors que Git fonctionne très bien sans GitLab.

## Git et GitLab : quelle différence

La question « git et gitlab c'est quoi » se pose généralement lorsque les deux termes apparaissent dans une offre d'emploi ou le premier jour de travail. La différence ressemble à celle qui existe entre un document et un espace de stockage en ligne : Git suit les modifications des fichiers et gère l'historique des commits et les branches en local. GitLab reçoit cet historique par le réseau et l'affiche dans le navigateur.

|  | Git | GitLab |
| --- | --- | --- |

| Ce que c'est | Programme de gestion de versions | Plateforme web pour dépôts et travail d'équipe |

| Où il fonctionne | Sur l'ordinateur du développeur | Sur gitlab.com ou sur le serveur de l'entreprise |

| Internet nécessaire | Non, sauf pour push, pull, fetch, clone | Oui, c'est un service réseau |

| Fonctions principales | Commits, branches, fusions, historique | Merge requests, revue, tâches, CI/CD, droits d'accès |

| Mode d'utilisation | Ligne de commande, IDE, clients graphiques | Navigateur plus les commandes Git habituelles |

Toutes les opérations sur le code (commit, branch, merge) se font toujours dans Git. GitLab reçoit le résultat par `git push` et permet de le discuter avec les collègues.

## GitLab et GitHub : les différences

Les deux services stockent des dépôts Git et prennent en charge la revue de code : les compétences de base se transposent donc telles quelles. Les différences tiennent aux priorités et au modèle de déploiement.

| Critère | GitLab | GitHub |
| --- | --- | --- |

| Demande de fusion | Merge request (MR) | Pull request (PR) |

| CI/CD | GitLab CI/CD intégré, fichier `.gitlab-ci.yml` | GitHub Actions, fichiers dans `.github/workflows/` |

| Installation chez soi | Community Edition gratuite sur son propre serveur | GitHub Enterprise Server, payant |

| Code source de la plateforme | Ouvert (Community Edition) | Fermé |

| Regroupement des projets | Groupes et sous-groupes imbriqués | Organisations |

| Où il est le plus répandu | Développement en entreprise, serveurs internes | Open source, projets publics, portfolios |

Dans la pratique, beaucoup de développeurs utilisent les deux : projets personnels et portfolio sur GitHub, code professionnel sur le GitLab de l'entreprise. Les commandes Git restent les mêmes ; seule l'adresse du dépôt distant change.

## gitlab.com ou serveur propre (self-hosted)

Le service cloud gitlab.com convient aux projets personnels et aux petites équipes : vous vous inscrivez et créez immédiatement vos dépôts. Les mises à jour, les sauvegardes et la disponibilité sont à la charge de GitLab. Les limites de l'offre gratuite (nombre de membres, minutes de CI, espace de stockage) évoluent de temps en temps ; consultez la page des tarifs pour les conditions actuelles.

Le GitLab auto-hébergé est installé par l'entreprise sur son propre serveur, à partir d'un paquet Linux, de Docker ou de Kubernetes. Le code ne quitte pas le réseau interne, vous pouvez brancher une authentification d'entreprise via LDAP et configurer vos propres runners pour les builds. En contrepartie, les administrateurs gèrent eux-mêmes les mises à jour et les sauvegardes. Pour un développeur, la différence est presque invisible : l'adresse n'est pas `gitlab.com` mais, par exemple, `gitlab.entreprise.fr`.

## Configurer Git pour travailler avec GitLab

Avant le premier commit, indiquez votre nom et votre adresse e-mail : ils figureront dans l'historique, et GitLab associera les commits à votre profil grâce à l'e-mail.

```
git config --global user.name "Jean Dupont"
git config --global user.email "jean@example.com"
```

Sous Windows, le plus confortable est Git Bash : il est installé avec Git pour Windows et contient `ssh-keygen`, si bien que toutes les commandes de cet article fonctionnent sans modification. Choisissez ensuite le mode de connexion : HTTPS avec un token, ou clé SSH.

### Connexion par HTTPS : personal access token

Pour les opérations Git en HTTPS, mieux vaut ne pas utiliser le mot de passe du compte ; avec l'authentification à deux facteurs activée, il ne fonctionne d'ailleurs pas. Créez plutôt un personal access token dans les paramètres du profil GitLab (section Access tokens). Pour travailler sur le code, les droits `read_repository` et `write_repository` suffisent ; définissez une durée de validité et enregistrez immédiatement le token, car il ne sera pas affiché une seconde fois.

Lors du premier push ou clone, Git demande un identifiant et un mot de passe : saisissez votre nom d'utilisateur GitLab, puis le token à la place du mot de passe. Le gestionnaire d'identifiants (intégré à Git pour Windows) le mémorise, et vous n'aurez plus à le saisir.

### Connexion par clé SSH

SSH est plus pratique au quotidien : une fois la clé ajoutée, vous n'avez plus rien à saisir.

```
ssh-keygen -t ed25519 -C "jean@example.com"
cat ~/.ssh/id_ed25519.pub
```

Collez le contenu du fichier `.pub` (clé publique) dans les paramètres du profil GitLab, section SSH Keys. Pour vérifier la connexion :

```
ssh -T git@gitlab.com
Welcome to GitLab, @jean.dupont!
```

## Git clone GitLab : cloner un dépôt

Sur la page du projet, le bouton Code affiche deux adresses : pour SSH et pour HTTPS. Copiez celle qui vous convient et lancez `git clone` :

```
# en HTTPS
git clone https://gitlab.com/mon-groupe/mon-projet.git

# en SSH
git clone git@gitlab.com:mon-groupe/mon-projet.git
```

Sur GitLab, le chemin d'un projet peut comporter des sous-groupes, par exemple `gitlab.com/entreprise/backend/api.git` : c'est normal, copiez l'adresse en entier.

### Git clone GitLab avec token

Dans les scripts et sur les serveurs où personne ne peut saisir de mot de passe, on transmet le token directement dans l'adresse. Le nom d'utilisateur peut être votre identifiant GitLab ou le nom technique `oauth2` :

```
git clone https://oauth2:VOTRE_TOKEN@gitlab.com/mon-groupe/mon-projet.git
```

Attention : une telle adresse est enregistrée dans `.git/config` et peut apparaître dans l'historique des commandes du shell. Pour l'automatisation, préférez un deploy token ou un project access token aux droits minimaux et à durée limitée ; dans la CI, utilisez la variable intégrée `CI_JOB_TOKEN`.

## Git push dans GitLab : envoyer le code

Si le projet existe déjà en local, créez un projet vide dans GitLab (sans README, pour éviter un commit supplémentaire) et reliez le dépôt distant :

```
git remote add origin git@gitlab.com:mon-groupe/mon-projet.git
git branch -M main
git push -u origin main
```

L'option `-u` relie la branche locale à la branche distante ; ensuite, `git push` et `git pull` suffisent. Le cycle de travail habituel ne diffère en rien de celui des autres services :

```
git switch -c feature/login
git add .
git commit -m "Ajouter le formulaire de connexion"
git push -u origin feature/login
git pull
```

Les tags s'envoient séparément : `git push origin v1.2.0`, ou tous à la fois avec `git push --tags`. Dans GitLab, les tags apparaissent dans la section Tags et déclenchent souvent le pipeline de publication d'une version.

### Erreurs courantes lors d'un git push dans GitLab

- **HTTP Basic: Access denied** — identifiant incorrect ou mot de passe saisi à la place du token. Créez un token avec le droit `write_repository` et supprimez l'ancienne entrée du gestionnaire d'identifiants.
- **Permission denied (publickey)** — GitLab ne reconnaît pas votre clé SSH. Vérifiez que la clé publique est ajoutée au profil, puis lancez `ssh -T git@gitlab.com`.
- **You are not allowed to push code to protected branches** — la branche (en général `main`) est protégée. Envoyez vos modifications dans votre propre branche et ouvrez une merge request.
- **rejected ... (fetch first)** — le serveur contient des commits que vous n'avez pas. Exécutez `git pull --rebase`, puis recommencez le push.
- **remote: Project not found** — faute de frappe dans l'adresse ou absence d'accès au projet ; précisez votre rôle auprès du propriétaire.

## Merge request dans GitLab

La merge request est l'équivalent de la pull request de GitHub : une demande d'intégration de votre branche dans la branche principale. C'est dans la MR que les collègues laissent des commentaires sur des lignes de code, que les vérifications CI s'exécutent et que la décision de fusion est prise. Après le push d'une nouvelle branche, GitLab affiche dans le terminal un lien pour créer la MR, et l'interface web propose de la créer.

Vous pouvez aussi créer une MR directement en ligne de commande, grâce aux options de push :

```
git push -o merge_request.create -o merge_request.target=main origin feature/login
```

Déroulement typique : branche pour la tâche → commits → push → MR → revue et pipeline vert → fusion. Lors de la fusion, GitLab peut regrouper les commits en un seul (squash) et supprimer la branche source. Si la MR présente un conflit, le plus simple est de mettre la branche à jour en local avec `git pull --rebase origin main` ou `git merge main`, de résoudre les conflits, puis de pousser à nouveau.

Marquez le travail inachevé comme Draft : une telle MR ne peut pas être fusionnée par erreur, mais les collègues voient déjà les modifications et peuvent les commenter.

## CI/CD dans GitLab : .gitlab-ci.yml

La grande particularité de GitLab est son CI/CD intégré. Il suffit de placer à la racine du dépôt un fichier `.gitlab-ci.yml` : à chaque push, GitLab lance un pipeline composé d'étapes (stages) et de tâches (jobs). Les tâches sont exécutées par des runners : gitlab.com en fournit de partagés, sur un serveur propre on les installe séparément.

```
stages:
  - test
  - deploy

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

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG
```

Ici, les tests s'exécutent à chaque push, tandis que la tâche `deploy` ne se lance que lorsqu'un tag est envoyé : `git tag v1.0.0`, puis `git push origin v1.0.0`. Les résultats du pipeline apparaissent directement dans la merge request, et vous pouvez empêcher la fusion tant que les vérifications ne sont pas passées.

## Comment supprimer un dépôt dans GitLab

Les commandes Git ne peuvent pas supprimer un projet sur le serveur : `git push` ne modifie que les branches et les tags. La suppression se fait dans l'interface web : paramètres du projet, section General, bloc Advanced, bouton de suppression avec confirmation par le nom du projet. Il faut le rôle Owner. La copie locale reste en place : ce n'est qu'un dossier contenant `.git`.

Si vous voulez détacher le dépôt local de GitLab sans rien supprimer sur le serveur, il suffit de lancer `git remote remove origin`.

## Quand choisir GitLab

- Le code ne doit pas sortir vers un cloud externe : il faut un serveur propre.
- Vous avez besoin d'un CI/CD opérationnel immédiatement, sans services tiers.
- Vous travaillez dans une grande organisation avec une hiérarchie d'équipes : les groupes imbriqués et les rôles flexibles sont utiles.
- Vous intégrez une entreprise qui utilise déjà GitLab : vous n'avez pas le choix, mais vos compétences Git se transposent entièrement.

Pour un portfolio ou l'open source, on choisit plus souvent GitHub, qui a une communauté plus large et une meilleure visibilité des projets. Rien n'empêche d'héberger un projet sur les deux services : un dépôt peut avoir plusieurs remotes.

## Conclusion

GitLab est une plateforme pour les dépôts Git, avec revue par merge requests, gestion des tâches et CI/CD intégré, disponible dans le cloud comme sur votre propre serveur. Le travail s'y résume à des commandes familières : configurez l'accès par token ou clé SSH, puis enchaînez clone, commit, push et merge request. Les dépôts distants et les workflows d'équipe sont traités en pratique dans le cours sur Git.

## FAQ

**GitLab est-il gratuit ?**

L'édition Community, à installer sur votre propre serveur, est gratuite ; sur gitlab.com, il existe une offre gratuite Free avec des limites. Les fonctions avancées sont proposées dans les offres payantes Premium et Ultimate.

**Peut-on migrer un projet de GitHub vers GitLab ?**

Oui : GitLab propose l'import de projets GitHub. Vous pouvez aussi transférer l'historique à la main avec git clone --mirror depuis l'ancienne adresse, puis git push --mirror vers la nouvelle.

**Faut-il apprendre des commandes spécifiques à GitLab ?**

Non, le code se gère avec les commandes Git habituelles ; GitLab ajoute l'interface web, et pour l'automatisation il existe l'utilitaire en ligne de commande glab ainsi que l'API.

**En quoi GitLab Flow diffère-t-il de Git Flow ?**

GitLab Flow est plus simple : le travail se fait dans des branches de fonctionnalité avec des merge requests vers main ; pour les environnements et les releases, on ajoute si besoin des branches dédiées, sans les branches develop et hotfix de Git Flow.


---
Source: Skillaria.Top (https://skillaria.top)