Les systèmes de gestion de version distribués
Comme nous l'avons évoqué précédemment, Git tente de remédier aux inconvénients des gestionnaires de version centralisés en proposant un VCS qui permet à la fois de disposer d’un dépôt complet en local sur un poste de travail et de ne plus stocker le contenu d'un projet en s’appuyant sur la notion de delta ou de différences entre chaque version d’un fichier.
Un dépôt (repository ou repo) dans Git correspond à un espace de stockage du code source où ce dernier est suivi et versionné. Il existe des dépôts distants (remote repositories) qui permettent de centraliser le code d'une équipe tout en favorisant la collaboration ou un dépôt local (local repository) qui peut être un répertoire personnel non partagé ou une copie d'un dépôt distant une machine locale.
I. La différence entre Git et les VCS centralisés
Ce qui différencie Git des VCS centralisés est qu’il fonctionne avec la notion de snapshot (« instantané »). À chaque commit ou nouvel enregistrement de l’état d’un projet, Git prend une photo complète (snapshot) du nouvel état des fichiers. Ce qui n’a pas changé n’est pas stocké à nouveau : le snapshot crée des pointeurs vers le contenu préexistant afin d'optimiser le stockage.
Ainsi, contrairement à sa contrepartie centralisée, Git crée donc une série de snapshots ou clichés instantanés distincts les uns des autres qui comprennent chacun l'état complet du projet à un moment donné :
Ce mode de fonctionnement est ce qui distingue Git des autres VCS qui stockent un fichier initial avec d'autres fichiers contenant les différences introduites à chaque nouvelle version. Dans Git, les snapshots sont conservés dans un fichier sous la forme d'une empreinte numérique (hash) qui résulte d’une somme de contrôle (checksum). Nous verrons plus loin que chaque commit correspond à un hash unique créé avec la fonction de hachage cryptographique SHA-1.
II. Fonctionnement d'un système de gestion de version distribué
Dans Git, presque toutes les opérations se font localement parce que c’est l’entièreté de l’historique d’un projet qui est récupérée sur le serveur distant. De cette manière, chaque contributeur possède un dépôt local complet à partir duquel il peut travailler.
- Enregistrer (faire un commit ou « commiter » ) les changements apportés à sa copie de travail vers son dépôt local.
- Envoyer (faire un push ou « pousser ») des modifications vers le dépôt distant.
- Mettre à jour ou récupérer (faire un pull) son dépôt local à partir du dépôt distant.
Les utilisateurs de Git désignent généralement le serveur distant comme dépôt de référence (souvent hébergé sur une plateforme web comme GitHub ou GitLab), mais chaque utilisateur peut aussi mettre à jour son dépôt à partir du poste de travail d’un autre contributeur, ce qui en fait un système de gestion de versions distribué et non centralisé.
En permettant d’avoir un dépôt local, Git réduit considérablement la dépendance avec les dépôts de référence qui résident sur un serveur distant. Il permet notamment de :
- Consulter l’historique d’un projet localement, car l’entièreté de celui-ci est disponible (voir plus haut la notion de snapshot).
- Travailler hors connexion puisqu’il est possible de mettre à jour son dépôt local plus tard lorsque l'accès réseau est disponible (travailler en avion en serait un bon exemple).
Maintenant que nous connaissons mieux le fonctionnement des systèmes de gestion de version, voyons en quoi il est essentiel d'utiliser un outil comme Git.
