Relancer une Pull Request

Reprendre une PR existante, la mettre à jour, traiter tous les retours et la préparer pour fusion. Cette compétence est agnostique du langage et du framework — substituez les commandes de build, lint, test et format réelles de votre projet où des exemples sont donnés.

Entrées

URL ou numéro de PR (obligatoire) : ex. https://github.com/<owner>/<repo>/pull/9996 ou #9996
Nom de branche (optionnel) : extrait des métadonnées de PR si non fourni

Workflow

1. Étudier la PR

Récupérez la PR via FetchUrl (ou gh pr view) pour obtenir :

Les changements de fichiers (diffs)
Les commentaires des relecteurs (inline et généraux)
Le statut du workflow CI et les logs
La description de PR et tout ticket lié

Lisez en profondeur tous les fichiers modifiés. Comprenez l'intention et la portée du changement.

Si la PR corrige un problème spécifique (ex. rapport d'erreur, bug signalé par un utilisateur) : enquêtez sur la cause racine avant de revoir le code. Confirmez que la correction résout le vrai problème. Parfois, les PR sont déjà supplantées par d'autres corrections.

2. Récupérer et Extraire la Branche

git fetch origin <branch-name> <base-branch>
git checkout <branch-name>

Si la branche n'existe pas localement, git checkout créera une branche de suivi à partir de origin/<branch-name>.

3. Rebaser sur la Branche de Base la Plus Récente

git pull origin <base-branch> --rebase

En cas de conflits :

Lisez chaque fichier en conflit pour comprendre les deux côtés
Résolvez les conflits en préservant l'intention de la PR tout en incorporant les changements de la branche de base
git add <resolved-files>
git rebase --continue

Si le rebase est propre : Vérifiez l'état avec git log --oneline -5 et git diff --stat origin/<base-branch>..HEAD.

4. Traiter les Commentaires des Relecteurs

Les commentaires des relecteurs ont déjà été récupérés à l'étape 1. Pour chaque commentaire non résolu :

Lisez le commentaire et comprenez ce qui est demandé
Faites la modification du code (ou expliquez pourquoi elle n'est pas nécessaire)
Ajoutez des tests si demandé
Committez la correction avec un message descriptif

Commentaires déjà traités : Vérifiez si une réponse existe déjà (champ in_reply_to_id). Ignorez les commentaires qui ont été résolus.

5. Exécuter les Vérifications CI Locales

Lancez les commandes de lint, format, typecheck/compile et test du projet pour les zones affectées. Découvrez-les en lisant la racine du repo (ex. Makefile, package.json, pyproject.toml, Cargo.toml, go.mod, build.gradle, mix.exs, Gemfile, composer.json, justfile, Taskfile.yml, README.md, ou la config du workflow CI).

Préférez les drapeaux filter / target pour limiter les exécutions aux zones affectées — c'est plus rapide que de lancer tout le repo. Motifs courants :

Monorepos JS/TS : npm run test -- --filter=<workspace>, pnpm -r --filter <pkg> test, nx test <project>
Python : pytest <path>, tox -e <env>
Rust : cargo test -p <crate>, cargo clippy -p <crate>
Go : go test ./<pkg>/..., golangci-lint run ./<pkg>/...
Java/Kotlin : ./gradlew :<module>:test, ./mvnw -pl <module> test
Bazel : bazel test //path/...

Consultez la section « CI Checks Reference » de la compétence create-pr pour un modèle plus large de commandes locales correspondant aux vérifications CI courantes.

Distinguer les défaillances préexistantes des problèmes de PR : Certaines défaillances CI existent sur la branche de base et ne sont pas liées à la PR. Si une défaillance se produit dans un fichier non touché par la PR, vérifiez qu'elle existe aussi sur la branche de base avant de passer du temps à la corriger. Les problèmes préexistants courants incluent les erreurs de résolution de modules / packages pour les dépendances récemment ajoutées.

Tests E2E : Si la PR change un comportement visible pour l'utilisateur (flux UI, paramètres par défaut, gestion du clavier, sortie CLI), les tests E2E peuvent échouer même si le code est correct. Lisez le test défaillant pour comprendre ce qu'il attend, puis mettez-le à jour pour correspondre au nouveau comportement. N'assumez pas que les défaillances E2E sont instables — lisez-les d'abord.

6. Committer et Pousser

git add -A
git commit -m "<type>(<scope>): <description>"

git push origin <branch-name> --force-with-lease

Si un bot de scan de commit bloque le push (Droid-Shield, GitGuardian, TruffleHog, etc.) : Cela arrive quand des fixtures de test non liées contiennent des chaînes qui ressemblent à des secrets. L'agent ne peut pas contourner cela. Demandez à l'utilisateur de pousser manuellement ou de désactiver temporairement le scanner selon la doc de votre org.

7. Répondre aux Commentaires des Relecteurs

Répondez à chaque commentaire traité sur la PR pour que les relecteurs sachent que leur feedback a été pris en compte.

Pour les commentaires de review inline (le type le plus courant) :

# Répondre à un thread de commentaire inline spécifique
gh api repos/<owner>/<repo>/pulls/<N>/comments/<COMMENT_ID>/replies \
  -X POST \
  -f body="<explication de ce qui a été fait>"

Pour un résumé au niveau de la PR :

gh pr comment <N> --body "<résumé de tous les changements effectués>"

Pour vérifier le statut de résolution du thread (optionnel) :

gh api graphql -f query='{
  repository(owner: "<owner>", name: "<repo>") {
    pullRequest(number: <N>) {
      reviewThreads(first: 20) {
        nodes {
          isResolved
          comments(first: 3) { nodes { body author { login } } }
        }
      }
    }
  }
}'

8. Mettre à Jour la Description de PR

Si les changements apportés lors du suivi sont significatifs (nouveaux tests, changements architecturaux, portée additionnelle), mettez à jour la description de PR :

gh pr edit <N> --body "<description mise à jour>"

Utilisez le format du modèle de PR de votre org. Mettez à jour la section de test pour refléter les tests additionnels ajoutés.

Vérification

Avant de considérer la tâche complète, confirmez :

[ ] Branche rebasée sur la dernière branche de base
[ ] Tous les commentaires des relecteurs traités par des changements de code
[ ] Lint local, typecheck/compile et tests passent pour les packages affectés
[ ] Changements poussés à la télécommande
[ ] Tous les commentaires des relecteurs ont des réponses expliquant ce qui a été fait
[ ] Description de PR à jour

follow-up-on-pr