Relis un diff, commente et traite une revue

L’idée reçue

« Une revue sérieuse doit trouver beaucoup de défauts. »

La valeur d’une revue vient du risque réduit et de la décision documentée, pas du nombre de commentaires.

01Commence par l’intention

Quel problème est résolu ?
Quelle branche reçoit le changement ?
Quel comportement doit changer ?
Qu’est-ce qui doit rester inchangé ?
Quelle preuve permet d’accepter ?
Quel rollback est possible ?

Lire les fichiers avant de comprendre l’objectif favorise les remarques locales sans vision du système.

02Examine le graphe et le diff

git fetch origin
git log --oneline --decorate origin/dev..origin/feature/backup-healthcheck
git diff --stat origin/dev...origin/feature/backup-healthcheck
git diff --check origin/dev...origin/feature/backup-healthcheck
git diff origin/dev...origin/feature/backup-healthcheck

03Relis par catégories de risque

Catégorie

Question

Preuve

Correction

le comportement répond-il au besoin ?

test ou observation reproductible

Sécurité

secret, droit ou entrée non contrôlée ?

scan, règle, configuration minimale

Exploitation

échec, journal, rollback ?

runbook et scénario d’erreur

Maintenance

la décision reste-t-elle compréhensible ?

noms, commits et documentation

04Rédige un commentaire actionnable

Contexte
Le runbook active le check mais ne donne pas le résultat attendu.

Risque
Un opérateur ne peut pas distinguer succès et sortie partielle.

Action demandée
Ajoute la commande de validation, la sortie minimale attendue et le rollback.

Évite « ce n’est pas clair ». Désigne le fichier, le risque et le critère de résolution.

05Choisis l’état de revue

Comment
Discussion ou suggestion non bloquante.

Approve
Le changement est acceptable selon le périmètre vérifié.

Request changes
Un risque identifié doit être traité avant intégration.

Une demande de changements ne bloque la fusion que si les règles du dépôt exigent une revue ou une approbation.

06Traite la remarque sans cacher l’évolution

# l’auteur corrige sur la même branche
$EDITOR docs/backup-validation.md
git add docs/backup-validation.md
git commit -m "docs: address backup validation review"
git push

Un commit correctif séparé facilite la seconde lecture. Le squash éventuel est une décision de fusion, pas une raison pour rendre la revue opaque.

07Revalide le nouveau head

git fetch origin
git rev-parse origin/feature/backup-healthcheck
git diff origin/dev...origin/feature/backup-healthcheck
gh pr checks
gh pr review --approve --body \
  "Validation et rollback désormais explicites."

L’approbation doit porter sur le SHA actuel. Selon les règles, un nouveau commit peut rendre l’approbation précédente obsolète.

08Observe les preuves du lab

cat /tmp/soria-git-github-$USER/evidence/review-result.txt
cat /tmp/soria-git-github-$USER/evidence/review-approval.txt
cat /tmp/soria-git-github-$USER/evidence/final-graph.txt

Le lab conserve la demande initiale, le changement ajouté et le SHA approuvé. Il ne prétend pas créer une vraie revue GitHub hors ligne.

Défi

Effectue une revue orientée risque

Choisis un diff de configuration. Produis une remarque bloquante, une suggestion non bloquante, le critère d’acceptation et la preuve attendue après correction.

✓À retenir

Une revue relie intention, risque et preuve. Après chaque modification du head, le diff et les checks doivent être relus avant l’approbation.