Versioning avec Git & GitHub · Étape 18

Publie une branche et ouvre une pull request

Prépare une branche révisable, vérifie son diff, publie-la avec upstream et ouvre une pull request qui explique intention, validation et rollback.

Durée indicative · ~1 h 35Niveau intermédiairePrérequis conseillé · Leçon 17 — authentification GitPratique · TP
L’idée reçue

« 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.
Mission

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.

Ta progression

Chargement de l’état… Se connecter pour synchroniser.