Ce qui rend un historique utile
Un historique Git ne sert pas à archiver, il sert à répondre à une question précise, presque toujours la même : pourquoi cette ligne est-elle comme ça ?
Six mois plus tard, personne ne se souvient. L'historique est le seul endroit où la réponse peut encore exister, et il ne la contiendra que si vous l'y avez mise.
Une branche par sujet
Une branche porte un changement et un seul. Ce n'est pas de la discipline gratuite : une branche qui mélange une correction urgente et une refonte ne peut plus être fusionnée ni annulée séparément, et vous vous retrouvez à devoir tout garder ou tout jeter.
git switch -c correctif-timeout-sauvegarde
Nommez la branche par le sujet, pas par votre prénom ni par la date. alex-2 ne dit rien à personne, y compris à vous dans quinze jours.
Le message de commit
La règle qui suffit : la première ligne dit ce qui change, le corps dit pourquoi.
Augmente le délai d'attente de la sauvegarde à 60 s
Le traitement de fin de mois dépasse 30 s sur la base de production
depuis la reprise des archives de 2024. La sauvegarde échouait une
nuit sur deux sans alerte, l'échec n'étant pas remonté.
Le « quoi » se lit dans le diff, donc l'écrire seul n'apporte rien. Le « pourquoi » n'existe nulle part ailleurs : c'est la seule information que vous êtes seul à pouvoir sauvegarder.
Un message qui commence par « fix », « update » ou « wip » fait perdre du temps à quelqu'un, plus tard, garanti.
Le commit qui se relit
Un commit contient un changement cohérent. Un commit de quarante fichiers mêlant reformatage automatique et changement de comportement est illisible : le changement réel disparaît dans le bruit du reformatage.
Séparez : un commit de forme, un commit de fond. Le premier se relit en dix secondes, le second mérite l'attention.
La relecture par un autre
Sur une branche partagée, faire relire n'est pas une formalité administrative. C'est le seul moment où quelqu'un d'autre que vous regarde le changement avant qu'il ne parte.
Trois questions pour un relecteur, dans l'ordre d'utilité : est-ce que je comprends pourquoi, est-ce que cela fait ce que le message annonce, et qu'est-ce qui casse si c'est faux.
Ce qui ne va jamais dans un dépôt
Rappel du chapitre précédent, parce que c'est l'erreur la plus coûteuse et qu'elle est irréversible en pratique : mots de passe, clés d'API, fichiers de configuration contenant des secrets.
Un secret poussé puis retiré par un commit suivant reste dans l'historique et reste récupérable. Le seul traitement correct est de considérer la clé comme compromise et de la révoquer immédiatement, avant même de nettoyer le dépôt.
À retenir
Une branche par sujet, nommée par le sujet. Le message dit pourquoi, parce que le quoi est déjà dans le diff. Séparez la forme du fond. Et un secret poussé est un secret à révoquer, pas à effacer.