Ton historique Git est illisible ?
C’est normal.
Tu l’utilises comme un bouton « Sauvegarder ».
Mais Git n’est pas un disque dur.
C’est un outil de communication.
Quand tu reviens sur un bug 6 mois plus tard, le code te dit ce qui a changé.
Mais il ne te dira jamais pourquoi tu as pris cette décision technique.
Voici comment redonner du sens à tes dépôts :
→ Commits atomiques
Un seul sujet par commit. Stop aux commits « Fix everything ».
→ Le Why > le How
Le « comment » est dans le diff. Le « pourquoi » doit être dans ton message.
→ Le Rebase avant fusion
Pour garder un graphe de commits linéaire, propre et lisible.
→ GitHub Flow
La simplicité absolue pour les équipes de moins de 6 personnes.
On oublie souvent que le code est lu 10 fois plus souvent qu’il n’est écrit.
Un historique propre, c’est un cadeau que tu fais à tes collègues (et à ton futur toi).
J’ai enregistré un talk complet sur le sujet : « Git raconte une histoire ».
J’y explique comment passer d’un fouillis technique à une documentation vivante.
Tu valides l’usage du Rebase pour garder un historique propre ?