1 · Anatomie d'une Pull Request

Une PR est bien plus qu'une simple demande de merge — c'est un espace de conversation et de validation.

Composants clés d'une PR

• Titre — Suivre les Conventional Commits : feat: ..., fix: ..., docs: ...
• Description — What (quoi), Why (pourquoi), How (comment), Test plan
• Liste des commits — Chaque commit visible individuellement
• Files changed — Diff complet, ligne par ligne, commentable
• Checks CI — Tests automatiques, linting, build
• Reviewers — Personnes assignées pour valider
• Labels — Catégorisation : bug, enhancement, breaking-change…
• Linked issues — Closes #42 ferme l'issue au merge

Draft Pull Request

Copier# Créer une PR en mode brouillon (work in progress)
gh pr create --draft --title "feat: [WIP] authentification JWT"

# Convertir en PR normale quand prêt
# → GitHub : bouton "Ready for review"
gh pr ready

2 · Templates de Pull Request

Un template PR standardise les informations à fournir à chaque contribution.

Emplacement du fichier

Copier.github/PULL_REQUEST_TEMPLATE.md
# ou pour plusieurs templates :
.github/PULL_REQUEST_TEMPLATE/feature.md
.github/PULL_REQUEST_TEMPLATE/bugfix.md

Template complet recommandé

Copier## What — Qu'est-ce que cette PR fait ?


## Why — Pourquoi ces changements sont-ils nécessaires ?

Closes #

## How — Comment avez-vous implémenté la solution ?


## Test plan
- [ ] Tests unitaires ajoutés / mis à jour
- [ ] Tests end-to-end validés
- [ ] Testé manuellement en local
- [ ] Pas de régression sur les features existantes

## Screenshots (si changements UI)
| Avant | Après |
|-------|-------|
| ...   | ...   |

## Checklist
- [ ] Code auto-documenté (commentaires pertinents)
- [ ] Pas de secrets dans le code
- [ ] CHANGELOG mis à jour si breaking change

3 · Stratégies de merge

GitHub propose 3 façons de merger une Pull Request, chacune avec un impact différent sur l'historique.

Comparaison de l'historique résultant

Copier# Merger via GitHub CLI
gh pr merge 47 --merge       # merge commit
gh pr merge 47 --squash      # squash and merge
gh pr merge 47 --rebase      # rebase and merge

# Avec suppression automatique de la branche
gh pr merge 47 --squash --delete-branch

4 · Code Review

Suggestion de code

Copier# Dans un commentaire de review sur GitHub :
# Cliquer sur le "+" en face d'une ligne → "Add a suggestion"
# Ou écrire manuellement :

```suggestion
const userEmail = input.trim().toLowerCase();
const isValid   = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(userEmail);
```

# L'auteur peut appliquer en 1 clic → commit automatique dans la PR
# Plusieurs suggestions peuvent être groupées en 1 commit

Checklist du reviewer

• Logique — Le code fait-il ce qu'il est censé faire ?
• Sécurité — Y a-t-il des injections, failles XSS, données sensibles exposées ?
• Performance — N+1 queries, boucles inutiles, fuite mémoire ?
• Tests — Les cas limites sont-ils couverts ?
• Lisibilité — Noms de variables clairs, fonctions courtes ?
• DRY — Code dupliqué qui pourrait être factorisé ?

CODEOWNERS — reviewers automatiques

Copier# .github/CODEOWNERS
# Format : <pattern> @owner ou @org/team

# Tout le code — team lead reviewe tout
* @team-lead

# API backend — team backend
/src/api/**   @org/backend

# Frontend — team frontend
/src/ui/**    @org/frontend

# Sécurité — toujours revue par le secops
/src/auth/**  @secops-team @team-lead

# Infrastructure
*.tf          @devops
docker*.yml   @devops

5 · Branch Protection Rules

Les règles de protection empêchent les modifications directes sur les branches importantes et garantissent la qualité.

• 👥
  Required pull request reviews Minimum 2 approbations avant le merge. Les "Dismiss stale reviews" annule les approbations si un nouveau push est fait.
• ✅
  Required status checks La CI (tests, lint, build) doit passer. "Require branches to be up to date" force le rebase avant merge.
• 🔒
  Restrict direct pushes Interdit les commits directs sur main — tout passe par une PR.
• 📏
  Require linear history Interdit les merge commits — force Squash or Rebase. Maintient un historique propre.
• 🗑️
  Restrict deletions Empêche la suppression de la branche protégée.

Configuration via API / GitHub CLI

Copier# Voir la protection d'une branche
gh api repos/OWNER/REPO/branches/main/protection

# Exemple de config JSON (via Settings > Branches sur GitHub)
{
  "required_status_checks": {
    "strict": true,
    "contexts": ["ci/tests", "ci/lint"]
  },
  "required_pull_request_reviews": {
    "required_approving_review_count": 2,
    "dismiss_stale_reviews": true
  },
  "restrictions": null,
  "enforce_admins": true
}

6 · Labels, Assignees, Reviewers & Issues liées

Workflow labeling recommandé

Copier# Ajouter un label via CLI
gh pr edit 47 --add-label "enhancement,ready for review"

# Assigner des reviewers
gh pr edit 47 --add-reviewer "collègue1,collègue2"

# Checker l'état des PR
gh pr list --state open --label "bug"

# Voir une PR spécifique
gh pr view 47 --web