Directives pour la Description de Pull Request
Lors de la rédaction d'une description de pull request (PR), votre objectif est de fournir aux relecteurs suffisamment de contexte pour comprendre ce que vous avez fait, pourquoi vous l'avez fait, et comment ils peuvent le vérifier. Une bonne description de PR accélère le processus de relecture et sert de documentation pour les futurs contributeurs.
Vérification d'Identité
Si vous êtes dans un environnement où il existe plusieurs identités GitHub (par exemple, une identité d'agent IA et une identité d'utilisateur principal), vous devez vérifier votre identité avant de faire un push ou de créer une PR.
Avant de committer, de faire un push ou d'ouvrir une PR, assurez-vous que vous utilisez l'identité que l'utilisateur attend en fonction du type de travail et du repository sur lequel vous travaillez. Vérifiez votre authentification GitHub CLI active (gh auth status) et assurez-vous que votre auteur de commit Git (git commit --author="...") correspond à la bonne identité pour la tâche.
Modèle de Description de PR
Utilisez toujours le modèle suivant (ou une structure très similaire) lors de la rédaction d'une description de PR :
## Summary
[Fournissez un résumé clair et concis, en 1-2 phrases, de ce que fait cette PR.]
## Motivation et Contexte
[Expliquez pourquoi ce changement est nécessaire. Quel problème résout-il ? S'il s'agit d'une correction de bug, quel était le comportement cassé ?]
## Issues Liées
[Si cette PR corrige une issue ouverte, créez un lien vers elle en utilisant des mots-clés. Par exemple, "Fixes #123" ou "Closes #456". Si elle est liée à une issue sans la fermer, utilisez "Related to #789".]
## Ce qui a changé
[Optionnel : Fournissez une liste à puces des changements techniques les plus importants effectués dans le code. C'est utile pour les PRs plus grandes.]
- Added `FooClass` to handle XYZ.
- Updated `BarMethod` to return `Result`.
## Instructions de Test
[Expliquez comment les relecteurs peuvent tester vos changements localement. Mentionnez les étapes de vérification manuelle éventuelles.]
- Run `dart test` to ensure all tests pass.
- [Any specific manual testing steps]
Ton et Style
- Soyez clair et concis : Évitez les digressions. Utilisez des listes à puces pour la lisibilité.
- Concentrez-vous sur le "Pourquoi" : Le diff montre ce qui a changé. La description doit expliquer pourquoi cela a changé.
- Soyez professionnel : Utilisez un langage naturel et accessible.
Exemples de Mauvais vs Bons Résumés
Mauvais : "Fixed the bug." (Trop vague, n'explique pas quel bug)
Mauvais : "Changed line 42 in main.dart to use foo instead of bar." (Se concentre trop sur le code, qui est visible dans le diff)
Bon : "Fixes a crash when the user clicks 'Submit' without entering an email address by adding validation to the input form." (Explique le problème et la solution)