Pendant des mois, je commitais n’importe comment. Des messages du genre fix, test2, ou le classique ça marche enfin ponctuaient mon historique Git comme autant de petites hontes. Et puis un jour, en revenant sur un projet après six semaines d’absence, j’ai été incapable de comprendre ce que j’avais fait. Mon propre code. Mon propre historique. Un désastre absolu.
La bonne nouvelle : cette galère est entièrement évitable. L’erreur que je faisais (et que font 90% des devs qui apprennent Git en autodidacte) ne concerne pas la commande elle-même, mais la philosophie derrière le commit. Git n’est pas un bouton « sauvegarder ». C’est un outil narratif. Et une fois qu’on intègre ça, tout change.
À retenir
- 90% des développés font la même erreur : pourquoi votre historique Git ressemble à une liste de courses froissée
- La règle cachée que personne ne t’apprend : ce que devrait vraiment contenir chaque commit
- Les trois réflexes qui transforment votre workflow Git en quelques jours seulement
Le mythe du « je commite souvent, donc je travaille bien »
L’idée reçue la plus répandue chez les débutants, c’est que multiplier les commits prouve qu’on est actif et rigoureux. Sauf qu’un historique Git rempli de wip et de modif css ne raconte aucune histoire cohérente. Quand un collègue (ou toi dans deux mois) doit comprendre pourquoi une ligne a changé, il va se retrouver à fouiller dans dix commits sans queue ni tête pour trouver un contexte qui n’existe pas.
Git repose sur une idée simple et puissante : chaque commit devrait représenter une intention claire et complète. Pas « j’ai touché des trucs », mais « j’ai corrigé le bug d’affichage sur mobile en retirant le padding fixe du header ». La différence entre ces deux messages, c’est la différence entre un journal de bord et une liste de courses froissée au fond d’une poche.
Mon erreur principale ? Je commitais en continu, à chaque micro-modification, sans jamais réfléchir à ce que représentait ce commit dans l’histoire du projet. Le résultat : un historique illisible, des git blame inutilisables, et une incapacité totale à faire un git revert propre quand quelque chose cassait.
La règle que personne ne t’apprend au début
Un commit = une idée. Pas une heure de travail, pas une feature entière non plus. Une idée. Un changement logique et cohérent qui pourrait tenir dans une phrase sans « et » ni « aussi ».
Si ton message de commit contient le mot « et », c’est le signal d’alarme. « Corrige le formulaire de contact et met à jour le footer » : voilà deux commits déguisés en un. Les séparer, c’est offrir à ton historique une granularité qui servira tôt ou tard, notamment le jour où tu voudras annuler l’un sans toucher à l’autre.
La convention qui m’a sauvé la mise, c’est le format dit « Conventional Commits » : on commence le message par un type (feat, fix, docs, refactor, chore…), suivi d’une description courte à l’impératif. Ça donne des trucs comme fix: corriger le calcul de TVA sur les produits exonérés ou feat: ajouter la pagination sur la liste des articles. En une ligne, n’importe qui comprend ce qui s’est passé et pourquoi.
Anecdote : Git a été créé par Linus Torvalds en 2005 pour gérer le développement du noyau Linux, un projet où des centaines de contributeurs envoyaient des patches simultanément. L’outil a été pensé dès le départ pour que des inconnus puissent comprendre le travail d’autres inconnus. Si ton historique ne permet pas ça, tu n’utilises pas Git, tu utilises une corbeille à papier avec un bouton « annuler ».
Concrètement, voici comment je travaille maintenant
La première habitude que j’ai adoptée : staging sélectif. Plutôt que de faire git add . en mode yolo, j’utilise git add -p (ou --patch). Cette commande te présente chaque bloc de modification et te demande si tu veux l’inclure dans le commit ou pas. C’est un peu plus lent, oui. Mais ça force à réfléchir à ce qu’on est en train de valider, et ça évite de commiter accidentellement un mot de passe, une clé API ou un console.log("ICIIIIII") oublié.
Deuxième réflexe que j’ai intégré : git commit --amend pour les petites corrections immédiates. Tu viens de commiter et tu réalises que tu as oublié un fichier ou que ton message est nul ? Amend règle ça proprement, sans créer un commit de honte fix oubli. Attention toutefois : on n’amende jamais un commit déjà pushé sur une branche partagée. Modifier l’historique public, c’est le meilleur moyen de provoquer des conflits chez tes collègues et de se faire regarder de travers en stand-up.
Troisième changement de comportement : j’ai arrêté de commiter directement sur main pour mes propres projets. Même seul sur un side-project. Créer une branche par fonctionnalité ou correction, puis merger proprement, c’est une discipline qui prend deux secondes à mettre en place et qui évite des heures de débug quand quelque chose part en vrille.
L’historique comme documentation vivante
Ce qui m’a vraiment changé la perspective, c’est de réaliser qu’un bon historique Git remplace souvent les commentaires dans le code. Quand quelqu’un fait un git log --oneline sur ton projet et voit une séquence lisible et logique, il comprend l’évolution du produit sans ouvrir un seul fichier. C’est une forme de documentation qui se maintient automatiquement si tu prends soin de tes messages.
À l’inverse, un historique chaotique force à lire le code ligne par ligne pour reconstruire le contexte. C’est du temps perdu, de la frustration accumulée, et souvent la raison pour laquelle les gens préfèrent réécrire from scratch plutôt que de comprendre l’existant.
La vraie question que je me pose maintenant avant chaque commit : si je quitte ce projet demain et qu’un inconnu le reprend dans six mois, est-ce que ce message lui suffit pour comprendre ce changement ? Si la réponse hésite, je reformule. C’est aussi simple et aussi radical que ça. Git n’a pas changé. C’est la façon de l’utiliser qui fait toute la différence entre un outil subi et un outil maîtrisé.