Versionning : Git et GitLab expliqués simplement
Dès qu’on travaille sur du code — seul ou en équipe — une question se pose vite : comment suivre les modifications, revenir en arrière en cas d’erreur, et travailler à plusieurs sans s’écraser mutuellement ? La réponse tient en un mot : le versionning (ou gestion de versions). Et l’outil qui domine le domaine s’appelle Git. Ce guide explique ce qu’est le versionning, comment Git fonctionne dans les grandes lignes, et ce que viennent faire GitLab et GitHub par-dessus.
Qu’est-ce que le versionning ?
Le versionning consiste à enregistrer l’historique des modifications d’un ensemble de fichiers au fil du temps. Chaque fois qu’on sauvegarde une étape, on crée une « version » à laquelle on pourra toujours revenir. Concrètement, cela apporte trois choses essentielles :
- Un historique complet : qui a changé quoi, quand, et pourquoi.
- La possibilité de revenir en arrière : annuler une modification qui a cassé quelque chose, retrouver une version qui fonctionnait.
- Le travail collaboratif : plusieurs personnes modifient les mêmes fichiers, et l’outil fusionne les changements intelligemment.
Sans versionning, on se retrouve vite avec des fichiers nommés projet_final.zip, projet_final_v2.zip, projet_vraiment_final.zip — une méthode fragile et ingérable à plusieurs. Git résout exactement ce problème.
Git, un système distribué
Créé en 2005 par Linus Torvalds (le créateur de Linux), Git est aujourd’hui le standard du versionning. Sa particularité est d’être distribué : chaque développeur possède sur sa machine une copie complète du projet et de tout son historique, pas seulement la dernière version.
Cela a des conséquences pratiques majeures : on peut travailler hors ligne, consulter tout l’historique sans connexion, et le projet n’est pas perdu si un serveur central tombe (chaque copie est une sauvegarde complète). C’est ce qui distingue Git des anciens systèmes centralisés comme SVN.
Les notions clés de Git
Quelques concepts reviennent sans cesse. En comprendre le principe suffit pour saisir la logique de Git :
| Notion | Rôle |
|---|---|
| Dépôt (repository) | Le projet versionné, avec tout son historique |
| Commit | Un « instantané » enregistré : une version datée et commentée |
| Branche (branch) | Une ligne de travail parallèle, pour développer sans toucher au reste |
| Fusion (merge) | Réunir le travail d’une branche dans une autre |
| Dépôt distant (remote) | Une copie partagée du projet, hébergée sur un serveur |
Le commit est le cœur du système : à chaque étape importante, on « fige » l’état du projet avec un message décrivant le changement. L’ensemble des commits forme l’historique, qu’on peut parcourir, comparer ou restaurer.
Les branches : travailler en parallèle
La force de Git tient beaucoup à ses branches. Une branche permet de développer une nouvelle fonctionnalité (ou corriger un bug) à l’écart de la version principale, sans risquer de la casser. Une fois le travail terminé et testé, on fusionne la branche dans la principale.
Ce mécanisme rend le travail à plusieurs fluide : chacun développe sur sa branche, et les contributions sont réunies proprement. C’est aussi ce qui permet de mener plusieurs chantiers en parallèle sur un même projet.
Git, GitHub, GitLab : quelle différence ?
C’est la confusion la plus fréquente. Distinguons clairement :
- Git est le logiciel de versionning, qui tourne sur votre machine. Il fonctionne parfaitement tout seul, en local.
- GitHub et GitLab sont des plateformes en ligne qui hébergent des dépôts Git et ajoutent des services autour : interface web, gestion des droits, suivi des tâches, revue de code, automatisation…
Autrement dit, Git est le moteur ; GitHub et GitLab sont des services bâtis dessus. On peut utiliser Git sans eux, mais ils facilitent grandement le travail d’équipe et le partage. GitHub est le plus connu (surtout pour l’open source) ; GitLab se distingue par ses fonctionnalités d’intégration continue et la possibilité de l’héberger soi-même — un atout en entreprise.
À quoi servent ces plateformes ?
Au-delà de l’hébergement, GitLab et GitHub apportent des outils devenus essentiels :
- La revue de code (merge/pull requests) : proposer des changements, les faire relire et commenter avant de les intégrer.
- Le suivi des tâches et bugs (issues).
- L’intégration continue (CI/CD) : lancer automatiquement des tests et des déploiements à chaque modification.
Ces fonctions transforment un simple outil de versionning en véritable plateforme de collaboration autour du code.
En résumé
Le versionning enregistre l’historique d’un projet et permet de revenir en arrière et de travailler à plusieurs sans conflit. Git en est l’outil de référence : distribué (chacun a une copie complète), organisé autour des commits et des branches. GitHub et GitLab sont des plateformes qui hébergent des dépôts Git et ajoutent revue de code, suivi des tâches et automatisation. Comprendre cette architecture est la première étape ; la suivante est de manier les commandes Git au quotidien, que nous détaillerons dans un article dédié. Nous consacrerons un article dédié aux commandes Git essentielles (clone, commit, push, branch, merge…) pour passer à la pratique.