Séquence 06 · Git n’est pas GitLab

Deux outils, deux mondes

On les confond tout le temps — les noms n’aident pas. Pourtant la distinction est simple, et une fois qu’elle est claire, la moitié des mystères de Git s’évaporent.

Une image d’abord

Mon ordinateur — Git L'outil installé sur votre poste. Le dépôt, l'historique, les commits : tout est là, chez vous. Git fonctionne intégralement sans réseau.
analyse.R rapport.qmd + l'album complet des commits
réseau ⇅
GitLab — la plateforme Un service sur le réseau qui héberge une copie du dépôt — et construit autour d'elle un lieu de travail commun pour l'équipe.

Git est la mémoire locale du projet : un outil qui tourne sur votre machine et tient l’album des versions. GitLab est une plateforme distante qui héberge une copie de cet album et y ajoute tout ce qui sert au collectif : consultation dans le navigateur, partage, droits d’accès, discussions, gestion de projet. Git existe sans GitLab. GitLab, lui, repose entièrement sur Git.

Ce que chacun sait faire

Git (votre poste) GitLab (la plateforme)
Où ça vit Sur votre ordinateur Sur un serveur, accessible en réseau
Photographier une version (commit)
Comparer, restaurer, feuilleter l’album consultation dans le navigateur
Fonctionner sans connexion
Centraliser le dépôt de référence de l’équipe
Partager le travail, gérer qui accède à quoi
Discuter d’une modification, suivre les tâches

Autrement dit : le travail de version se fait chez vous, avec Git ; la mise en commun se fait sur GitLab. Les deux se synchronisent — c’est l’objet de la séquence suivante.

GitLab n’est pas « une sauvegarde de mes fichiers ». C’est le dépôt de référence de l’équipe : le lieu où l’étude officielle vit, se consulte et se partage. La nuance compte : une sauvegarde, on n’y pense qu’en cas de pépin ; le dépôt commun, c’est là que vos collègues travaillent vraiment — et ce qu’on y envoie doit être digne de leur confiance.

« Distribué » : chacun a l’album complet

Souvenez-vous du « Pour aller plus loin » de la séquence 01 : Git est dit distribué. Voici ce que cela signifie concrètement :

  • Le poste de Marie contient le projet et tout l’historique ;
  • le poste de Franck contient le projet et tout l’historique ;
  • GitLab contient le projet et tout l’historique.

Trois copies complètes de l’album. Si le serveur tombe, rien n’est perdu ; si un poste est réinstallé, rien n’est perdu. Chaque copie peut reconstituer les autres. C’est ce qui rend l’ensemble si robuste — et c’est pour cela que « GitLab = simple sauvegarde » est un contresens : c’est un pair parmi les copies, celui que l’équipe a choisi comme point de rencontre.

Pour aller plus loin — GitHub, Gitea, Bitbucket… c’est pareil ?

Oui : GitHub, Gitea, Bitbucket ou l’instance GitLab interne de votre administration jouent tous le même rôle de plateforme au-dessus de Git. Les commandes Git que vous apprenez aujourd’hui sont identiques quelle que soit la plateforme — seuls changent l’interface web et quelques services annexes. Si votre service migre un jour de GitLab vers autre chose, vos réflexes resteront valables à 100 %.

Le réseau de votre bâtiment est en panne toute la matinée. Que pouvez-vous faire ?

Question pour vous, sans bouton ni bonne réponse cachée : dans votre équipe, aujourd’hui, où vit « la » version de référence de vos études ? Un dossier réseau ? La boîte mail ? Le poste d’une seule personne ? Qu’est-ce que cela implique le jour où cette personne est absente ?

Reste à faire voyager les commits entre votre poste et GitLab.

Séquence 07 — Synchroniser