communicationFonctionne bien avec ClaudeFonctionne bien avec ChatGPTFonctionne bien avec Copilot

Rédiger des messages de commit et des descriptions de PR à partir de votre diff

De bons messages de commit et descriptions de pull request permettent à un changement de s'expliquer lui-même, aux relecteurs d'aujourd'hui comme à quiconque devra le déboguer dans deux ans. Mais à la fin d'une longue tâche, écrire le pourquoi plutôt que le quoi est le raccourci que presque tout le monde prend. Résumer les changements de code récents fait partie des cinq tâches IA les plus courantes ; soumettre le diff à un modèle produit un brouillon structuré que vous modifiez ensuite pour ajouter le raisonnement qu'il ne peut pas voir.

Vous m'aidez à rédiger un message de commit clair et une description de pull request à partir d'un diff. Suivez les conventions de mon équipe.

Convention de commit (par exemple Conventional Commits) ou « aucune » : {{convention}}
Pourquoi j'ai fait ce changement — l'intention qu'un diff ne montre pas : {{intent}}
Le diff :
{{diff}}

Produisez deux choses :
1. Un message de commit : une ligne de sujet concise (mode impératif, environ 50 caractères, suivant {{convention}} si indiqué), une ligne vide, puis un corps expliquant ce qui a changé et pourquoi, avec un retour à la ligne à 72 caractères. Référencez le ticket sous la forme « [ISSUE] » que je remplirai.
2. Une description de PR : un résumé d'un paragraphe, une liste à puces des changements notables, une section « Comment tester » et une note « Risque / retour arrière ».

Règles :
- Décrivez uniquement ce qui figure réellement dans le diff. N'affirmez pas que des tests ont été ajoutés, que la documentation a été mise à jour ou qu'un bug a été corrigé, sauf si le diff le montre. Marquez tout ce que vous ne pouvez pas confirmer à partir du diff par « [VERIFY] ».
- Le pourquoi doit provenir de mes notes d'intention, pas de votre supposition sur ma motivation.
- Pas de remplissage, pas de reformulation du code ligne par ligne, pas de ton marketing.

Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.

Convention de commit (ou aucune)Pourquoi vous avez fait ce changementLe diff (collez la sortie de git diff)

Ce que vous obtenez (extrait)

feat(api) : mettre en cache les recherches de permissions utilisateur Les vérifications de permissions sollicitaient la base de données à chaque requête, ajoutant de la latence. Mise en cache des permissions résolues par utilisateur pendant 60 s pour réduire les requêtes redondantes. Ferme [ISSUE]. --- Résumé de la PR : ajoute un cache en mémoire de courte durée pour les recherches de permissions. Changements notables : - Nouvelle PermissionCache avec un TTL de 60 s - Cache invalidé lors d'un changement de rôle Comment tester : appelez /me deux fois ; le second appel doit sauter la base de données (voir le log de debug). Risque / retour arrière : le cache est derrière le flag PERM_CACHE ; désactivez-le pour revenir en arrière. [VERIFY] invalidation lors de déploiements multi-instances.

Le flux de travail complet

Indexez (stage) le diff final et notez une ligne sur la raison d'être du changement
Générez le message et la description, puis corrigez tout ce que le diff ne justifie pas réellement
Renseignez les numéros de ticket et tout repère « [VERIFY] » à la main
Gardez le raisonnement dans le corps du message — c'est la partie dont les relecteurs et votre futur vous ont réellement besoin

Attention à

Un modèle qui résume un diff affirmera volontiers que vous avez ajouté des tests ou corrigé un problème de sécurité alors que ce n'est pas le cas — un historique de commits est un enregistrement permanent sur lequel d'autres s'appuient, donc vérifiez chaque affirmation par rapport au diff avant de committer.

Les diffs peuvent contenir des secrets, des clés ou des identifiants internes. Ne les collez pas dans un outil grand public ; utilisez une intégration approuvée ou nettoyez-les d'abord.

Le modèle voit le quoi mais pas le pourquoi. Fournissez vous-même l'intention, sinon vous livrerez des messages qui décrivent le changement sans expliquer la décision qui le sous-tend.

D’où ça vient

Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les développeurs en exercice — rien n’est inventé par nous.

Plus de cas d’usage de l’IA pour les développeurs

analyse

Rédiger des messages de commit et des descriptions de PR à partir de votre diff

Le flux de travail complet

Attention à

D’où ça vient

Plus de cas d’usage de l’IA pour les développeurs

Faire expliquer un code inconnu avant de le modifier

Une première relecture de votre diff avant qu'un humain ne le voie

Générer des tests unitaires que vous validez ensuite par rapport à la spécification

Déboguer avec la méthode du canard en plastique un problème qui vous résiste

Transformer une décision en ADR ou dans la documentation que vous aviez sautée