Créer une Pull Request

Créez une PR avec les conventions appropriées : vérification locale, titre Conventional Commits, un corps de modèle, et un ticket lié optionnel. Cette compétence est agnostique du langage et du framework — remplacez les commandes de compilation, lint, test et formatage de votre projet où des exemples sont montrés.

Prérequis

Avant de commencer, vérifiez :

1. La branche actuelle a des commits qui ne sont pas sur la branche de base (git log origin/<base-branch>..HEAD --oneline)
2. La branche est poussée vers le dépôt distant (git push -u origin HEAD si ce n'est pas fait)
3. Aucun changement non validé qui devrait être inclus (git status)

Flux de travail

1. Comprendre les modifications

Exécutez en parallèle :

git log origin/<base-branch>..HEAD --oneline
git diff origin/<base-branch>..HEAD --stat

Déterminez :

• Qu'a changé : Quels modules, packages, services ou répertoires ont été modifiés
• Type de modification : feat, fix, docs, refactor, test, chore, perf, ci, build, revert
• Portée : Module/package/service principal affecté (utilisez le nom du répertoire ou monorepo / repo pour les modifications transversales)
• Est-ce un changement de code ? : Si la PR modifie le code source (pas seulement la documentation, le markdown ou les changements de config), exécutez la liste de vérification locale à l'étape 2 avant de créer la PR.

2. Vérification locale (pour les changements de code)

Ignorez cette étape si la PR ne touche que la documentation, des fichiers markdown ou d'autres fichiers non-code. Pour tout changement qui touche les fichiers source, exécutez les commandes de vérification de votre projet localement avant de créer la PR.

Découvrez les commandes en lisant la racine du dépôt (p. ex. Makefile, package.json, pyproject.toml, Cargo.toml, go.mod, build.gradle, mix.exs, Gemfile, composer.json, justfile, Taskfile.yml, README.md, ou le fichier de config du flux CI). Utilisez les drapeaux de filtre/cible le cas échéant (p. ex. turbo --filter, nx --projects, pnpm --filter, bazel //path/..., cargo -p <crate>, pytest <path>, go test ./<pkg>/...) pour exécuter uniquement les portions affectées — c'est plus rapide que d'exécuter tout le dépôt.

Catégories de vérification courantes à exécuter le cas échéant :

Vérification de type / Compilation

Exécutez l'étape de vérification de type statique ou de compilation du projet s'il en a une.

Exemples dans différents écosystèmes (utilisez ce que le dépôt définit) :

• TypeScript : npm run typecheck, pnpm -r typecheck, tsc --noEmit
• Python (typé) : mypy ., pyright, ty check
• Rust : cargo check
• Go : go build ./..., go vet ./...
• Java/Kotlin : ./gradlew compileJava, ./mvnw compile

Lint / Formatage

Exécutez le linter et le formateur du projet. Préférez une cible de correctif automatique si elle existe.

Exemples :

• JS/TS : npm run fix, npm run lint, eslint ., prettier --check .
• Python : ruff check --fix ., ruff format ., black ., flake8
• Rust : cargo clippy --all-targets, cargo fmt --check
• Go : golangci-lint run, gofmt -l .
• Shell : shellcheck, shfmt -d .

Tests

Exécutez les tests unitaires/intégration pour les packages affectés.

Exemples :

• JS/TS : npm run test -- --filter=<workspace>, pnpm -r test, vitest run <path>, jest <path>
• Python : pytest <path>, tox -e <env>, python -m unittest
• Rust : cargo test -p <crate>
• Go : go test ./<pkg>/...
• Java/Kotlin : ./gradlew test, ./mvnw test
• Ruby : bundle exec rspec <path>, rake test

Vérifications supplémentaires (à exécuter si pertinent)

• Exports inutilisés / code mort : Exécutez la vérification de code mort de votre projet s'il en a une (p. ex. knip, ts-prune, vulture pour Python, deadcode / unused pour Go, cargo udeps pour Rust).
• Hygiène des dépendances : Exécutez la vérification des dépendances de votre projet s'il en a une (p. ex. depcheck, pip check, cargo audit, bundle audit).
• Fichier de verrouillage synchronisé : Si vous avez modifié un manifeste de dépendance (package.json, requirements.txt, pyproject.toml, Cargo.toml, go.mod, Gemfile, etc.), exécutez la commande d'installation (npm install, pnpm install, uv sync, poetry lock --no-update, cargo update -w, go mod tidy, bundle install) et validez les changements du fichier de verrouillage. La CI échoue couramment si le fichier de verrouillage est obsolète.
• Code généré / codegen : Si le dépôt a une spec OpenAPI, protobuf, schéma GraphQL, migrations SQL, ou tout autre artefact généré, régénérez et validez les changements.
• Linters de style / assets : Exécutez les linters de feuilles de style (stylelint, etc.) ou les linters d'assets si vous avez modifié ces fichiers.
• Scans de sécurité : Exécutez les scanners de sécurité/secrets configurés dans le dépôt (trivy, semgrep, gitleaks, etc.).

3. Lier à un ticket (optionnel)

Si votre organisation utilise un suivi des problèmes, demandez à l'utilisateur de :

• Créer un nouveau ticket : Utilisez l'outil approprié (Linear, Jira, GitHub Issues, etc.)
• Lier un ticket existant : Demandez l'identifiant (p. ex. TEAM-1234, JIRA-567, #42)
• Ignorer : Seulement si l'utilisateur dit explicitement qu'aucun ticket n'est nécessaire

La plupart des systèmes CI peuvent être configurés pour exiger l'identifiant du ticket dans le corps de la PR. Suivez la convention de votre organisation.

4. Formater le titre de la PR

Suivez Conventional Commits : type(scope): description

• type : feat, fix, docs, refactor, test, chore, perf, ci, build, revert
• scope : Nom du module/package/service/répertoire affecté, ou monorepo / repo pour les modifications transversales. Plusieurs scopes peuvent être séparés par des virgules : fix(a, b, c): ...

Exemples :

• feat(web): add dark mode toggle
• fix(cli, daemon): load shell env at entrypoint
• fix(api): handle nil response from upstream
• chore(repo): bump dependencies

5. Générer le corps de la PR

Remplissez toutes les sections de votre modèle de PR. Un modèle typique a quatre sections :

## Description

<résumé concis de ce qui a changé et pourquoi>

## Related Issue

Closes TEAM-XXXX
<!-- ou : Part of TEAM-XXXX -->

## Potential Risk & Impact

<liste des risques, implications de performance, dettes techniques>
<!-- Utilisez « N/A » seulement si vraiment aucun risque -->

## How Has This Been Tested?

<décrivez les tests effectués : tests unitaires, tests manuels, typecheck, lint>

6. Créer la PR

gh pr create \
  --base <base-branch> \
  --head <branch-name> \
  --title "<type>(<scope>): <description>" \
  --body "<generated body>"

Si le corps est long, écrivez-le dans un fichier temporaire et utilisez --body-file :

gh pr create --base <base-branch> --head <branch> --title "..." --body-file /tmp/pr-body.md

7. Signaler le résultat

Retournez l'URL de la PR à l'utilisateur.

Référence des vérifications CI (modèle)

Il s'agit des catégories de vérification typiques qui s'exécutent sur chaque PR. Mappez-les aux commandes réelles de votre dépôt lors de l'adaptation de cette compétence.

Vérifications toujours exécutées

Vérifications conditionnelles (exécutées seulement quand les fichiers affectés changent)

• Validation API / schéma : Déclenchée par les changements API ou schéma. Régénérez localement.
• Compilations spécifiques à la plateforme : Déclenchées quand les cibles desktop/mobile/embedded sont affectées.
• Tests E2E : Déclenchés quand l'app consommatrice ou le binaire de haut niveau est affecté.

Conventions de PR typiques que la CI applique

• Nom de branche : Longueur max, caractères autorisés (p. ex. [A-Za-z0-9/-]).
• Titre : Format Conventional Commits avec une portée valide.
• Référence de ticket : Le corps de la PR doit contenir un identifiant de ticket (souvent ignoré pour les types chore: et revert:).

Erreurs courantes à éviter

• Mauvaise branche de base : Utilisez la branche dans laquelle votre organisation accepte les PRs (p. ex. dev, main, develop, trunk).
• Portée manquante : La vérification CI du titre de la PR requiert souvent une portée valide.
• Référence de ticket manquante : La description doit référencer votre ID de ticket pour que la CI passe (sauf chore:/revert:).
• Oublier de pousser : La branche doit être sur le dépôt distant avant gh pr create.
• Dérive du fichier de verrouillage : Exécutez toujours la commande d'installation et validez les changements du fichier de verrouillage après des changements de dépendances.
• Ignorer les vérifications locales sur les PRs de code : La vérification de type/compilation, lint et les tests doivent être exécutés localement avant d'envoyer les changements de code pour détecter les problèmes rapidement et éviter les allers-retours de CI.
• Artefacts générés non validés : Après les changements API/schéma, régénérez et validez.