Chapitre 4.5.1
Introduction à Git

Imagine 10 personnes dans une pièce. Chacune reçoit une copie d'un discours de 500 lignes. Isolées dans leur coin, elles doivent corriger le discours et en reformuler des parties. À la fin, il faut combiner le travail de tout le monde pour produire un discours unique, cohérent, qui fonctionne.

C'est mission impossible sans un outil qui permet de voir les ajouts et suppressions de chacun, de garder en mémoire les différentes versions du texte, et de combiner les contributions tout en résolvant les cas où deux personnes ont modifié la même ligne.

Le code informatique n'est rien d'autre que du texte. Les développeurs sont donc quotidiennement confrontés à ce problème. Plus l'équipe est grande, plus le besoin de contrôle est élevé.

C'est le rôle d'un outil de contrôle de versions.

Un peu d'histoire

Le besoin de suivre les modifications d'un fichier est aussi vieux que l'informatique collaborative. Dès les années 70, des outils émergent pour garder une trace des changements. Mais ils sont rudimentaires : un seul fichier à la fois, un seul utilisateur à la fois. Quand quelqu'un verrouille un fichier pour le modifier, personne d'autre ne peut y toucher.

Pendant 30 ans, les outils se perfectionnent. CVS dans les années 90, puis SVN dans les années 2000, introduisent le travail collaboratif : plusieurs personnes peuvent modifier le même fichier en même temps, et un serveur central gère les fusions. SVN devient le standard de l'industrie pendant une bonne décennie.

Tous ces outils partagent un point commun : ils sont centralisés. Un serveur unique détient l'historique complet du projet. Si le serveur tombe, personne ne peut travailler. Si ta connexion est coupée, tu ne peux même pas consulter l'historique de tes propres fichiers.

En 2005, Linus Torvalds, le créateur du noyau Linux, se retrouve dans une impasse. L'outil qu'il utilisait retire sa licence gratuite à la communauté Linux. Des milliers de développeurs contribuent au noyau. Il a besoin d'un outil rapide, fiable, et surtout décentralisé.

En quelques semaines, il crée Git.

Pourquoi décentralisé ?

Avec Git, chaque développeur possède sur sa machine une copie complète du projet et de tout son historique. Tu peux travailler hors ligne, consulter l'historique, enregistrer des modifications... tout ça sans jamais te connecter à un serveur.

En pratique, les équipes utilisent quand même un dépôt central pour partager leur travail. Mais ce dépôt n'est pas un point unique de défaillance : si le serveur tombe, chaque développeur possède une copie complète. On peut tout reconstruire.

L'autre avantage majeur : la vitesse. Comme les opérations courantes sont locales, elles s'exécutent en quelques millisecondes, là où les anciens outils centralisés pouvaient prendre plusieurs secondes pour chaque interaction avec le serveur.

Comment ça marche au quotidien ?

Revenons à notre discours écrit par 10 personnes. Avec Git, le flux de travail ressemble à ça :

1. Cloner : tu télécharges une copie complète du projet et de son historique sur ta machine.
2. Travailler : tu modifies les fichiers comme d'habitude.
3. Enregistrer : tu "commit" tes fichiers. Tu prends une photo instantanée de leur état à cet instant. Chaque commit est accompagné d'un petit message décrivant ce que tu as fait : "Ajout de la conclusion", "Correction de la faute page 3".
4. Partager : tu envoies tes commits vers le dépôt central pour que les autres puissent les récupérer. On appelle ça "pousser" (push) ses modifications.
5. Récupérer : tu télécharges les commits des autres et Git les fusionne avec ton travail. On dit "tirer" (pull) les dernières mises à jour.

Ce cycle se répète plusieurs fois par jour. La tendance est aux commits fréquents et petits : plus un commit est ciblé, plus il est facile à comprendre et à annuler si besoin.

L'historique

Chaque commit s'empile sur le précédent pour former un historique. C'est le journal de bord (les logs) du projet. On peut remonter le temps jusqu'au tout premier commit, voir qui a modifié chaque ligne et quand.

Un bon historique Git est formé de commits logiquement découpés, avec des messages lisibles. En entreprise, c'est souvent la première source de documentation consultée pour comprendre pourquoi le code est dans cet état.

Les développeurs adoptent d'ailleurs de plus en plus des conventions d'écriture des messages pour obtenir un rendu uniforme et parlant pour tous.

On comprend tout de suite que ce commit corrige un accord dans la conclusion.

Les conflits

Git est remarquablement intelligent pour fusionner le travail de plusieurs personnes. Si deux développeurs modifient des fichiers différents, ou même des parties différentes du même fichier, la fusion est automatique et transparente.

Mais quand deux personnes modifient la même ligne, Git ne peut pas deviner quelle version garder. Il signale un conflit et demande à un humain de trancher : garder l'une des deux versions, les combiner, ou écrire quelque chose de complètement différent.

Les conflits sont bien souvent anodins. Parfois cependant, ils obligent le développeur à se plonger dans le code pour le repenser complètement. Les éditeurs de code modernes proposent tous des interfaces qui facilitent le processus en affichant les deux versions côte à côte.

Un outil pour tous

Git n'est pas qu'un outil technique réservé aux développeurs. C'est un outil de collaboration utilisable par toute l'équipe.

Grâce à Git, un chef de projet peut suivre l'avancement du développement en regardant les commits récents. Un nouvel arrivant peut comprendre l'évolution du projet en parcourant l'historique.

Bien que Git soit majoritairement utilisé pour versionner du code, il peut fonctionner sur tous les textes et même sur d'autres types de fichiers. Les graphistes peuvent garder les étapes de création de leurs visuels, les auteurs peuvent collaborer sur l'écriture de livres...

Git est aujourd'hui devenu le leader incontesté du contrôle de versions. Il est intégré dans tous les éditeurs de code modernes et utilisé par la quasi-totalité des équipes de développement dans le monde.