Git raconté aux gens normaux : le classeur des versions

Souviens-toi du drame du cahier unique. Tu écris ta rédaction, tu changes d’avis sur la fin, tu ratures, tu arraches la page, tu recommences… et au moment de rendre, tu te dis que la première fin était mieux. Trop tard : elle est dans la poubelle de la classe.

Des années plus tard, le drame a juste changé de costume. Sur ton ordinateur, il s’appelle rapport-final.docx, rapport-final-2.docx, rapport-final-2-VRAIMENT-final.docx. Même panique, mêmes questions : c’était laquelle, la bonne ? Qu’est-ce qui a changé entre les deux ? Et si je supprime, je perds quoi ?

Les développeurs ont réglé ce drame il y a vingt ans avec un outil au nom peu engageant : git. Et je vais te le raconter comme promis la semaine dernière : sans une seule ligne de code. Parce que tu n’as pas besoin de savoir te servir de git — tu as besoin de comprendre ce qu’il fait, car c’est là-dessus que ton agent et toi allez collaborer.

Le classeur qui n’oublie rien

Imagine un classeur posé à côté de ton cahier. À chaque fois que tu veux garder une étape, tu enregistres un instantané des changements suivis dans le classeur, avec un message : « intro terminée », « nouvelle conclusion, plus courte ».

C’est l’image du suivi de versions : un commit (prononce « commite ») enregistre un instantané des fichiers sélectionnés, accompagné d’un message et d’informations de date et d’auteur. L’ensemble des commits reliés s’appelle l’historique. Le dossier qui contient les données Git et les fichiers du projet est un dépôt (repository, ou « repo » pour les intimes).

L’historique permet souvent de retrouver une ancienne version des changements enregistrés. Mais Git ne sauvegarde pas magiquement tout : un fichier non suivi, une modification jamais enregistrée, un dépôt endommagé ou un historique réécrit peut échapper au classeur. Il reste utile d’avoir des sauvegardes adaptées. Tu peux remplacer les fichiers VRAIMENT-final-2.docx par une copie de travail, mais l’historique ne protège que ce qui a été suivi et enregistré.

Comparer deux copies : le surligneur magique

Deuxième super-pouvoir du classeur : tu peux sortir deux photocopies, les poser côte à côte, et git te surligne uniquement ce qui a changé entre les deux. Trois mots modifiés dans un texte de dix pages ? Trois mots surlignés. Ce comparateur s’appelle le diff.

Repense à l’article sur la supervision : pour corriger la copie de ton agent sans tout relire, il te faut voir ce qu’il a touché. Le diff, c’est ça. Quand ton agent te dit « j’ai modifié le fichier », le diff montre les changements suivis entre deux états. Tu peux ainsi commencer ta relecture par les lignes touchées, sans croire qu’il juge leur justesse à ta place. C’est l’outil de travail numéro un du correcteur.

Les branches : photocopier sa copie pour essayer une autre fin

Maintenant, le concept qui fait peur dans les livres et qui est en fait tout bête : les branches.

Ta rédaction est propre, mais tu as une idée de fin complètement différente. Tu peux créer une branche pour isoler des changements et essayer cette autre fin. Cela ne crée pas forcément une copie indépendante de chaque fichier : Git enregistre des instantanés et les branches sont des repères mobiles dans cet historique. Tu peux ensuite abandonner la branche ou fusionner son travail ; une mauvaise manipulation ou un fichier modifié ailleurs peut tout de même affecter le cahier du propre.

C’est tout. Une branche est un repère de travail dans l’historique. Le cahier du propre s’appelle en général la branche main (la « principale »). Et recopier les bonnes idées de la photocopie vers le propre s’appelle une fusion (merge).

Pourquoi ça te concerne ? Parce que c’est comme ça qu’un agent bien élevé travaille : tu peux lui demander de faire ses essais sur une branche distincte au lieu de modifier la branche principale. Tu regardes le diff, tu annotes, et seulement quand c’est bon, tu peux intégrer les changements dans le propre. Un mauvais brouillon peut encore toucher tes fichiers si l’agent a les droits : la branche n’est pas une protection automatique.

Le casier de l’école : partager le classeur

Dernier morceau. Ton classeur est chez toi — mais ta copie doit voyager : vers tes camarades de groupe, vers ton agent, vers l’imprimerie du journal de l’école. Alors il existe un casier partagé, un endroit où tout le monde peut déposer et récupérer le classeur. Le plus connu de ces casiers s’appelle GitHub (« le hub des git » — littéralement le vestiaire à classeurs).

Deux gestes courants : envoyer tes commits vers un dépôt distant — push — et intégrer les changements distants à ton travail — pull. Plusieurs commandes et stratégies de synchronisation existent ; le casier n’intègre pas toujours les changements sans conflit. Quand ce blog te disait dans les coulisses que chaque article part « dans le git » avant d’être imprimé sur le site, c’était ça : je range l’article dans le classeur (commit), je le dépose au casier (push), et l’imprimerie de l’école prend le relais.

À retenir : Git enregistre l’historique des changements suivis. Un commit est un instantané accompagné d’un message ; le diff compare deux états ; une branche est un repère pour faire évoluer le travail. Ces outils facilitent comparaison et retour arrière, sans remplacer la sauvegarde ni garantir que rien ne sera perdu. Push/pull synchronisent le dépôt avec un dépôt distant comme GitHub.

Pourquoi c’est LE filet de sécurité de la délégation

Récapitulons ce que ce classeur change quand tu travailles avec un agent. Tu peux voir les changements suivis (le diff), puis concentrer ta relecture sur les parties modifiées. Tu peux comparer des changements et parfois restaurer un état antérieur, si les données nécessaires sont toujours présentes. Une branche séparée, des droits limités et une sauvegarde renforcent ce filet ; aucun de ces mécanismes ne garantit qu’un agent ne modifiera pas le mauvais fichier ou que chaque action sera récupérable. Tous les conseils de supervision de l’article précédent deviennent dix fois plus faciles avec ce filet en dessous.

À toi de jouer : tu utilises déjà un classeur sans le savoir

Pas besoin d’installer quoi que ce soit pour toucher l’idée du doigt. Ouvre un document Google Docs (ou Word en ligne) sur lequel tu as travaillé plusieurs jours, et cherche le menu « Historique des versions ». Regarde : toutes tes anciennes versions sont là, datées, avec les changements surlignés. Tu peux en rouvrir une vieille, comparer, restaurer.

Ça, c’est un classeur de versions — un git de poche, automatique et simplifié. Git s’en approche : c’est toi (ou ton agent) qui décides quels changements enregistrer et comment les décrire, et il permet aussi de travailler avec des branches et de comparer des fichiers. Ensuite, la prochaine fois que ton agent modifie des fichiers pour toi, pose-lui LA question du correcteur outillé : « montre-moi ce que tu as changé avant que je valide ». Tu viens de demander un diff. Bienvenue au club.

À la publication de cette série, l’article suivant abordait le travail planifié. Cette annonce éditoriale ne signifie pas que le présent texte a été produit ou publié par une tâche automatique ; les articles peuvent être préparés à l’avance.