Le Workflow Pull Request (PR)

SlidesPDFPPTX

Niveau : Intermediate

Durée : 2h

Prérequis

• Maîtriser branches, merge et collaboration GitHub (Ateliers 05-07)
• Savoir faire git push -u et git fetch/pull
• Avoir un repo GitHub avec droits de push

Objectifs d'apprentissage

• Expliquer le workflow PR en 7 étapes (Issue→Branch→Commit→Push→PR→Review→Merge)
• Créer une PR via UI et via gh pr create, avec Draft et templates
• Gérer reviewers, CODEOWNERS, et les types de review
• Appliquer les bonnes pratiques de revue (petites PRs, bienveillance, checks)

Progression dans cet atelier0%

Pourquoi les PRs ?Créer la branche & pousserOuvrir la PR (UI & gh)Draft vs ReadyReview & CODEOWNERSMerge & suite

---

Pourquoi les Pull Requests ?

Sans PR, tout le monde pousse sur main → chaos, régressions, pas de recul.

Avec PR, chaque changement :

• est présenté (titre + description),
• est discuté ligne-par-ligne,
• est validé par des pairs,
• déclenche la CI (tests).

<pre dir="ltr" class="mermaid">flowchart LR A[Issue&lt;br/&gt;bug/feature] --&gt; B[Branch&lt;br/&gt;feature/xxx] B --&gt; C[Commits&lt;br/&gt;conventionnels] C --&gt; D[Push&lt;br/&gt;origin/feature] D --&gt; E[Pull Request&lt;br/&gt;Draft → Ready] E --&gt; F[Review&lt;br/&gt;Approve / Request changes] F --&gt; G[Checks&lt;br/&gt;CI vert] G --&gt; H[Merge&lt;br/&gt;squash/merge/rebase]</pre>

Sans PR

git push origin main direct → main cassé → rollback d’urgence

Avec PR

feature → PR → 1 approbation + CI → merge → main protégé

1. Push Local

git push origin branch

2. Ouvrir la PR

Sur GitHub

3. Code Review

Retours & Corrections

4. Merge PR

Fusionné dans main

---

Préparer : créer la branche & pousser

1. Issue → assignez-vous la tâche Closes #42 2. Branch depuis main à jour : bash git switch main git pull origin main git switch -c feature/bouton-bleu 3. Commits atomiques 4. Push avec upstream

Commandes à exécuter

1

git switch -c feature/bouton-bleuCrée la branche dédiée.

2

echo 'button { background: blue; }' > style.cssAjoute la feature.

3

git add style.cssStage.

4

git commit -m "feat: add bouton bleu"Commit conventionnel.

5

git push -u origin feature/bouton-bleuPush + upstream.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$_

Commandes à exécuter

1

gh repo view --webOuvre le repo sur GitHub.

2

git push -u origin feature/bouton-bleuPush classique.

3

gh pr create --draft --fillCrée la PR en draft directement.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$_

---

Ouvrir la PR : UI & Templates

Via UI GitHub

1. Bandeau jaune Compare & pull request → Cliquez
2. Titre : feat: add bouton bleu (Closes #42)
3. Description — utilisez le template :

## Contexte

Closes #42

## Changements

- Ajout style bouton bleu

## Screenshots

![bouton bleu]

## Checklist

- [x] Tests verts
- [x] Pas de secret commité

Templates dans .github/PULL_REQUEST_TEMPLATE.md et .github/ISSUE_TEMPLATE/* remplissent automatiquement.

Via gh

gh pr create --title "feat: add bouton bleu" --body "Closes #42" --draft
gh pr create --fill  # remplit depuis les commits
gh pr view --web
gh pr checkout 42
gh pr view 42 --json state,reviewDecision

---

Draft vs Ready & États

État	Signification	Mergeable ?
Draft	Brouillon, WIP, CI peut tourner, pas de review requise	❌ Non
Ready for review	Prête, reviewers notifiés	✅ Si checks verts
Changes requested	Un reviewer a demandé des corrections	❌ Attend nouveau push
Approved	1+ Approve	✅
Merged	Fusionnée dans main	—
Closed	Abandonnée	—

Convertir :

gh pr ready 42
gh pr ready 42 --undo

---

Review : CODEOWNERS, reviewers, types

CODEOWNERS — reviewers auto

.github/CODEOWNERS

# Frontend → @org/frontend-leads
*.js    @joinhashcode/frontend
/docs/  @joinhashcode/docs-team
*       @joinhashcode/tech-leads

Toute PR touchant *.js notifie automatiquement frontend.

Types de review

• Comment — question, sans bloquer
• Approve — LGTM, on peut merger
• Request changes — bloque le merge jusqu’à correction
• Suggestion — Suggestion sur une ligne → bouton Commit suggestion

Bienveillance Le but n’est pas de juger, mais d’améliorer la qualité ensemble.

Pour l'auteur

• Petite PR (<300 lignes) → revue en 15 min - Description claire + screenshots - Répondez à tous les commentaires, même avec un emoji

Pour le reviewer

• Expliquez le pourquoi, pas juste le quoi - Proposez une alternative : suggestion - Approve dès que le fond est OK (nit = non bloquant) - Après correction : re-request review ou nouveau Approve

Commandes à exécuter

1

gh pr view 42 --json reviewDecision --jq .reviewDecisionVoir la décision.

2

echo 'fix: address review' >> style.css && git commit -am "fix: address review" && git pushCorrige et repousse — la PR se met à jour auto.

3

gh pr view 42 --json reviewDecision --jq .reviewDecisionAprès nouvel approve.

4

gh pr merge 42 --squash --delete-branchMerge en squash + suppression branche distante.

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$_

---

Merge, protections & suite

Stratégies

• Merge commit → garde tous les commits (git merge --no-ff)
• Squash → 1 commit propre sur main (recommandé pour features)
• Rebase → historique linéaire (avancé, réécrit l’historique)

Branch Protection (Atelier 14)

main doit être protégée : pas de push direct, 1 Approve requis, CI verte.

Force-push après review

Sur votre branche de feature corrigée, préférez toujours :

git push --force-with-lease

à --force : Git refuse si la branche distante a bougé sans que vous le sachiez (ex. merge de CI).

---

Fiches de révision

Question

Qu'est-ce qu'une PR ?

Cliquer pour révéler la réponse

Réponse

Demande de fusion d'une branche (feature/xxx) dans main, avec description, review et CI.

Cliquer pour voir la question

Question

Commande pour pousser une feature prête à PR ?

Cliquer pour révéler la réponse

Réponse

git push -u origin feature/xxx

Cliquer pour voir la question

Question

Draft vs Ready ?

Cliquer pour révéler la réponse

Réponse

Draft = brouillon non mergeable. Ready = prête pour review et merge.

Cliquer pour voir la question

Question

À quoi sert CODEOWNERS ?

Cliquer pour révéler la réponse

Réponse

Assigner automatiquement les reviewers selon les fichiers modifiés (ex: *.js → @frontend).

Cliquer pour voir la question

Question

3 types de review ?

Cliquer pour révéler la réponse

Réponse

Comment, Approve, Request changes (bloquant). + Suggestions.

Cliquer pour voir la question

Question

Que mettre dans une description de PR ?

Cliquer pour révéler la réponse

Réponse

Contexte (Closes #), changements, screenshots, checklist tests.

Cliquer pour voir la question

Question

Comment créer une PR en draft via gh ?

Cliquer pour révéler la réponse

Réponse

gh pr create --draft --fill ou --title --body

Cliquer pour voir la question

Question

Pourquoi petites PRs ?

Cliquer pour révéler la réponse

Réponse

Revue plus rapide, moins de bugs, feedback tôt.

Cliquer pour voir la question

---

Quiz Final

1. Qu'est-ce qu'une Pull Request ?

AUne commande Git pour pullBDemande de fusion d'une branche dans main sur GitHubCUn raccourci git pull + requestDUn fichier de config

2. Pourquoi garder les PRs petites ?

AÉconomiser du disqueBRevue plus rapide et moins d'erreursCGitHub limite à 300 lignesDÉviter les conflits

3. Quelle commande crée une PR draft via gh ?

Agh pr create --draft --fillBgit pr create --draftCgh issue create --draftDgit push --draft

4. Que fait CODEOWNERS ?

ADéfinit la licenceBAssigne auto les reviewers selon les fichiersCBloque les pushesDCrée des labels

---

Cheat Sheet

# Préparer
git switch main && git pull origin main
git switch -c feature/xxx
git commit -m "feat: xxx" && git push -u origin feature/xxx

# Créer PR
gh pr create --draft --fill
gh pr create --title "feat: xxx" --body "Closes #42"
gh pr view --web
gh pr checkout 42

# Review
gh pr view 42 --json reviewDecision
gh pr review --approve
gh pr review --request-changes --body "…"

# Draft ↔ Ready
gh pr ready 42
gh pr ready 42 --undo

# Merge
gh pr merge 42 --squash --delete-branch
gh pr merge 42 --merge
gh pr merge 42 --rebase

---

Mini Challenge

Votre Progression0%

• Créer une Issue 'feat: bouton bleu' et vous l'assigner.
• Depuis main à jour, créer feature/bouton-bleu, committer et pousser avec -u.
• Ouvrir une Draft PR via gh pr create --draft --fill, vérifier le template.
• Passer en Ready, demander une review à un pair, traiter un Request changes (push fix), obtenir Approve.
• Merger en squash + supprimer la branche, vérifier git log --oneline sur main.

---

Carte mentale

---

À retenir

• Le workflow moderne protège main : Issue → Branch → Commits → Push → PR Draft → Review → Merge squash.
• Une PR petite (<300 lignes) avec un template clair se review en 15 minutes.
• CODEOWNERS automatise les reviewers, gh pr automatise la création et le suivi.

Erreurs fréquentes

• Ouvrir une PR depuis main au lieu d’une feature → toujours git switch -c feature/xxx depuis main à jour.
• Pousser sans -u puis git push échoue → git push -u origin feature/xxx au premier push.
• Laisser une Draft en attente → penser à gh pr ready.
• Commenter sans Approve → la PR reste bloquée par la branch protection.

Prochaine étape

PR maîtrisée, voyons comment organiser le travail à l’échelle du projet : Issues, labels, Projects, milestones.

Étape suivante : Gestion de Projet GitHub

Et maintenant ?

Prochain atelier

9. Gestion de Projet GitHub

Labs associés

Lab Niveau 09 — Pull RequestsLab Niveau 10 — Code Review