« Une pull request est seulement une demande de merge. »
C’est une unité de décision : intention, diff, discussion, checks, approbations et preuve de livraison doivent permettre une intégration consciente.
01Vérifie la branche de départ
git fetch --prune origin
git switch dev
git pull --ff-only origin dev
git switch -c feature/backup-healthcheck
Une branche créée depuis une base obsolète augmente les conflits et rend la revue moins lisible.
02Découpe le travail
git status --short
git diff
git add platform.conf
git diff --cached
git commit -m "feat: enable backup health check"
git add docs/backup-validation.md
git commit -m "docs: add backup validation runbook"
Deux intentions distinctes produisent ici deux commits. Le reviewer peut comprendre ou annuler chaque étape séparément.
03Relis comme GitHub
git log --oneline origin/dev..HEAD
git diff --stat origin/dev...HEAD
git diff --check origin/dev...HEAD
git diff origin/dev...HEAD
Les trois points comparent le travail de la branche depuis son ancêtre commun avec la base, ce qui correspond au périmètre utile de la proposition.
04Publie avec upstream
git push -u origin feature/backup-healthcheck
git status --short --branch
git branch -vv
Le push ne crée pas automatiquement une décision d’intégration. Il rend la branche disponible au remote.
05Ouvre la pull request
gh pr create \
--base dev \
--head feature/backup-healthcheck \
--title "feat: enable backup health check" \
--body-file .github/pull_request_template.md
Utilise –draft lorsque le travail doit être visible et testable mais n’est pas encore prêt pour une décision de merge.
06Écris un corps vérifiable
## Pourquoi
Le staging ne vérifie pas l’état des sauvegardes.
## Changements
- activation du health check ;
- runbook de validation et rollback.
## Validation
- commande exécutée ;
- résultat attendu observé ;
- aucun secret ou artefact généré.
## Rollback
Revenir à `backup_check=disabled`.
Évite les formulations comme « ça marche ». Indique la commande, le contexte, le résultat et la limite de la validation.
07Contrôle la PR depuis le terminal
gh pr view --web
gh pr diff
gh pr checks
gh pr status
Un check vert démontre uniquement ce que ce check exécute. Il ne prouve pas une validation navigateur, un test Windows ou un déploiement réel si ces étapes ne sont pas dans le pipeline.
08Évite les PR impossibles à relire
Signal d’alerte
- plusieurs objectifs sans relation ;
- fichiers générés ou binaires mélangés au code ;
- refactoring et fonctionnalité dans le même diff ;
- centaines de lignes sans plan de validation ;
- branche ancienne avec conflits tardifs ;
- secret masqué seulement dans l’interface.
Prépare une PR exploitable
Utilise le template généré par le lab. Fournis le graphe, les commits, le diff stat, la validation, le rollback et les limites de ce qui n’a pas été testé.
✓À retenir
Une bonne pull request réduit l’incertitude. Elle part de la bonne base, contient un diff limité et donne au reviewer les preuves nécessaires pour décider.