Pourquoi versionner son code (Git), même quand on travaille seul

Pourquoi garder l'historique d'un code quand on est seul à y travailler ? Parce que le jour où un changement casse tout, vous pouvez revenir à l'état d'hier en quelques instants. Cet historique s'appelle le versionnage, et l'outil le plus répandu pour le faire s'appelle Git.

Ce que fait Git

Git enregistre l'histoire d'un projet : chaque changement, qui l'a fait, quand, et pourquoi. Chaque enregistrement, qu'on appelle un commit, est un point auquel on peut revenir.

L'analogie la plus parlante : l'historique des modifications d'un document partagé, mais pour tout un projet, fichier par fichier, avec un message qui explique chaque changement.

L'analogie : le carnet de bord d'un navire

Un capitaine note dans son journal chaque cap, chaque manœuvre, chaque incident. Si le bateau se retrouve au mauvais endroit, il relit le journal, repère où la route a dévié et corrige.

Un projet sans Git, c'est un navire sans journal : on sait où l'on est, mais plus comment on y est arrivé, et on ne peut pas refaire le chemin.

Pourquoi c'est utile même seul

• Revenir en arrière. Un essai tourne mal ? On retrouve la dernière version qui fonctionnait.
• Comprendre un bug. « Ça marchait la semaine dernière » : on peut chercher quel changement a tout cassé.
• Essayer sans risque. On peut travailler sur une branche, une copie parallèle du projet, tester une idée, et ne la garder que si elle convainc.
• Garder une copie ailleurs. Un projet Git est généralement hébergé sur un service en ligne : si votre ordinateur tombe en panne, le travail est sauvegardé. Ce n'est pas une sauvegarde complète en soi (voir sauvegarde et réplication), mais c'est un grand pas.
• Se relire soi-même. Dans six mois, les messages de vos commits expliquent des choix que vous aurez oubliés.

Pourquoi c'est encore plus utile à plusieurs

À deux ou plus, Git permet à chacun de travailler sur sa partie sans écraser celle des autres, puis de fusionner les changements. Il signale quand deux personnes ont modifié la même ligne, au lieu de laisser l'une effacer l'autre en silence.

Il permet aussi la relecture : un collègue regarde les changements avant qu'ils entrent dans le code principal, ce qui attrape des erreurs tôt.

Ce que Git n'est pas

• Pas un outil réservé aux grandes équipes. Il sert dès le premier jour d'un projet.
• Pas un dossier de secrets. Les mots de passe et clés d'accès ne doivent pas être enregistrés dans l'historique : même supprimés ensuite, ils restent lisibles dans les anciennes versions (voir les clés API exposées).
• Pas une sauvegarde de vos données. Git garde le code, pas le contenu de votre base de données.

Ce qu'il faut exiger d'un projet

Si vous confiez ou faites reprendre un produit, quelques vérifications rapides :

1. Le code est-il dans un dépôt Git, et vous appartient-il, avec un accès à votre nom ?
2. L'historique est-il lisible, avec des messages qui disent ce qui a changé, plutôt que « modif » cent fois ?
3. Le code principal est-il distinct des essais, avec une version stable identifiée ?
4. Les secrets sont-ils absents de l'historique ?

Un projet livré sans historique est possible à reprendre, mais plus difficile à comprendre, et le moindre changement prend plus de temps et comporte plus de risque.

À retenir

Git est le journal de bord de votre code : il rend chaque changement réversible et explicable. Même seul, c'est la première habitude à prendre, et la première chose à vérifier dans un projet qu'on vous remet.

Et pour votre produit ?

Si vous héritez d'un code sans historique clair, ou dont personne ne sait plus ce qui est en ligne, le premier travail est de remettre de l'ordre. C'est l'un des points qu'on regarde dans une reprise de projet. Si vous voulez voir où en est votre code, parlons-en pendant 30 minutes.