jksim/agent-skills-jksim

Hygiène des Commits

Aperçu

Règle 4 des règles de Jarrett : un changement ne contient que les commits dont il a logiquement besoin. Un relecteur lit un seul commit propre par changement, pas un historique de tentatives. Les commentaires sont courts.

Le hook commit-check prévient lorsqu'un message de git commit dépasse les limites. Il ne bloque pas. Vous corrigez le commit.

Quand l'utiliser

• Avant chaque commit.
• Avant chaque push.
• Lorsque vous avez fait plus d'un commit pour corriger un seul problème.
• Lorsque le hook commit-check prévient.

Processus

1. Rédiger le message

• Sujet : 72 caractères ou moins. Utilisez l'impératif : « Ajouter le hook de règles », pas « Ajouté le hook de règles ».
• Corps : 5 lignes ou moins. Omettre lorsque le sujet suffit.
• Dites ce qui a changé et pourquoi. Ne décrivez pas chaque fichier.
• Utilisez un anglais simplifié. Voir la compétence simplified-english.

2. Faire un seul commit par changement logique

• Un changement logique : une tranche de fonctionnalité, un correctif ou un refactoring qu'un relecteur peut accepter ou rejeter comme une unité.
• Ne mélangez pas un refactoring et un changement de comportement dans un même commit.
• Ne commitez pas chaque tentative. Commitez lorsque le changement fonctionne et que les tests passent.

3. Écraser les commits de correction avant le push

Un commit de correction corrige un commit antérieur dans le même changement. Exemples : « fix typo », « wip », « prise en compte de la relecture ».

1. Faites le commit de correction avec git commit --fixup <sha>.
2. Écrasez-le sans éditeur : GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base>.
3. Si le rebase s'arrête sur un conflit, corrigez les fichiers et exécutez git add <fichiers>. Puis exécutez GIT_EDITOR=true git rebase --continue. Pour arrêter, exécutez git rebase --abort.
4. Relancez les tests.
5. Vérifiez le résultat : git log --oneline <base>..HEAD.

Si le dernier commit est celui à corriger, utilisez git commit --amend --no-edit.

Attention : ne réécrivez pas les commits déjà sur une branche partagée. Demandez d'abord à l'utilisateur. Une réécriture oblige chaque coéquipier à réinitialiser.

4. Garder les commentaires courts

• Écrivez un commentaire uniquement lorsque le code n'est pas clair.
• Une ligne suffit généralement. Dites pourquoi, pas quoi.
• N'écrivez pas d'historique de modifications dans les commentaires. Git conserve l'historique.

Rationalisations Courantes

Rationalisation	Réalité
« Les petits commits montrent ma progression. »	Le relecteur a besoin du résultat, pas du chemin. Écrasez les tentatives.
« Un long message donne plus de contexte. »	Les longs messages ne sont pas lus. Mettez le contexte dans la spécification ou la PR.
« J'écraserai plus tard. »	Plus tard, c'est après le push. Écrasez avant le push.
« Le hook ne fait que prévenir, donc la limite est facultative. »	La limite est une règle d'équipe. Le hook prévient pour que vous puissiez la corriger.

Drapeaux Rouges

• git log affiche « wip », « fix », « oops » ou « try again » avant le push.
• Plus d'un commit pour un seul correctif de bug.
• Un corps de commit qui liste chaque fichier modifié.
• Des commentaires qui répètent ce que dit le code.

Vérification

• Chaque sujet fait 72 caractères ou moins et utilise l'impératif.
• Chaque corps fait 5 lignes ou moins.
• git log --oneline <base>..HEAD montre un commit par changement logique.
• Aucun commit de correction n'est laissé avant le push.
• Les tests passent après tout rebase.

Limite connue : le hook ne vérifie pas git -C <dir> commit ni git -c <clé>=<valeur> commit. Il ignore également certains messages qu'il ne peut pas lire, par exemple -F <fichier>.