1.1 : Git, c'est quoi ? L'analogie de l'établi et du registre du forgeron

Vous faites déjà du versionnage, mais mal

Ouvrez le dossier Scripts de votre partage réseau. Il y a de fortes chances que vous y trouviez quelque chose qui ressemble à ça :

Maj-AD.ps1
Maj-AD_v2.ps1
Maj-AD_v2_final.ps1
Maj-AD_v2_final_OK.ps1
Maj-AD_v2_final_OK - Copie.ps1
Maj-AD_ancien_NE_PAS_SUPPRIMER.ps1

Aucun administrateur système n’a jamais décidé, un matin, de créer ce genre d’arborescence. Elle apparaît toute seule, parce qu’elle répond à un besoin parfaitement légitime : avant de modifier un script qui fonctionne, on veut pouvoir revenir en arrière. Le suffixe _v2 est une sauvegarde. Le - Copie est un filet de sécurité. Le NE_PAS_SUPPRIMER est un aveu d’incertitude.

Autrement dit, vous faites déjà de la gestion de versions. Vous la faites simplement avec le seul outil dont vous disposiez : le nom du fichier.

Et cette méthode a trois défauts qui finissent toujours par se payer.

Elle ne dit pas ce qui a changé. Entre _final et _final_OK, il y a peut-être une correction de bug critique, peut-être une virgule. Pour le savoir, il faut ouvrir les deux fichiers et comparer à l’œil, ligne par ligne.

Elle ne dit pas pourquoi. Le nom du fichier ne contient aucune intention. Six mois plus tard, personne — pas même vous — ne saura si cette v2 corrigeait un incident ou testait une idée abandonnée.

Elle ne dit pas qui, ni quand. La date de modification NTFS vous donne la dernière écriture, pas l’historique. Si trois personnes ont touché le fichier en six mois, il n’en reste aucune trace.

Git, c’est exactement ce système de suffixes — mais fait correctement, par un outil dont c’est le seul métier.

La définition, en une phrase

Git est un système qui enregistre l’état complet d’un ensemble de fichiers à chaque fois que vous le lui demandez, en conservant à chaque enregistrement l’auteur, la date et la raison du changement.