Session 15 : Pull Requests : la porte d'entrée de ton projet

Tu as construit une feature sur une branche. De bons commit messages, du travail propre. Maintenant tu veux mettre ton code dans master.

Tu pourrais faire git merge et c’est fini. Mais en équipe, ça ne marche pas. Quelqu’un d’autre doit d’abord regarder ton code : vérifier les erreurs, le style, les choses que tu as oubliées. Voilà ce qu’est une pull request.

Une pull request (PR) est une demande : « Récupère mes modifications. » Tu l’ouvres sur GitHub. Tes coéquipiers regardent ton code, donnent du feedback. Toi, tu modifies des choses. C’est seulement quand tout le monde est content que le code part vers master.

Dans cette session, tu fais ta première pull request. Tu reviewes celle d’un buddy. Et tu découvres ce que ça fait vraiment, le travail d’équipe avec Git.

Ce que tu vas apprendre aujourd’hui

  • Ce qu’est une pull request et pourquoi les équipes l’utilisent
  • Ouvrir une PR sur GitHub
  • Mettre à jour ta PR après du feedback
  • Reviewer la PR de quelqu’un d’autre
  • Merger une PR et nettoyer la branche

Étape 0 : Préparation : travailler en duo

Aujourd’hui, tu travailles avec un buddy. Décidez qui est l’auteur (celui qui construit la feature) et qui est le reviewer (celui qui regarde la PR). À la moitié, vous échangez.

L’auteur a besoin d’un repo GitHub auquel le reviewer a accès. La façon la plus simple :

  1. L’auteur crée un repo sur GitHub (public).
  2. L’auteur va dans Settings → Collaborators → Add people.
  3. L’auteur invite le reviewer avec son username GitHub.
  4. Le reviewer accepte l’invitation (par e-mail ou via les notifications GitHub).

Maintenant, vous pouvez tous les deux pusher vers le même repo.

Alternative (sans accès collaborator) : le reviewer forke le repo de l’auteur et ouvre une PR depuis le fork vers l’original. Mais aujourd’hui, on garde ça simple : accès collaborator direct.

Étape 1 : Créer et pusher une branche feature (auteur)

L’auteur clone le repo (si ce n’est pas encore fait) et crée une branche feature :

git clone https://github.com/AUTEUR_USERNAME/ons-samenwerk-project.git
cd ons-samenwerk-project
git switch -c feature/groet-functie

Crée un nouveau fichier :

echo 'def groet(naam):' > groet.py
echo '    return f"Hallo {naam}!"' >> groet.py

Committe et pushe :

git add groet.py
git commit -m "Add groet function

Retourne une salutation pour le nom donné."
git push -u origin feature/groet-functie

Étape 2 : Ouvrir une pull request (auteur)

  1. Va sur ton repo sur GitHub.
  2. GitHub affiche maintenant une barre jaune : « feature/groet-functie had recent pushes » : clique sur Compare & pull request. (Si tu ne vois pas la barre : clique sur l’onglet Pull requests, puis New pull request, choisis base: master ← compare: feature/groet-functie.)
  3. Écris un titre clair : « Add groet function »
  4. Écris une description. Une bonne description de PR a trois parties :
## Quoi

Une fonction `groet(naam)` qui retourne une salutation.

## Pourquoi

On a besoin d'une salutation réutilisable pour
l'interface utilisateur. Ça évite de devoir écrire
la même string à plusieurs endroits.

## Comment tester

```python
from groet import groet
print(groet("CoderDojo"))  # "Hallo CoderDojo!"
5. Clique sur **Create pull request**.

Ta PR est maintenant ouverte. Toute personne qui a accès au repo peut la voir. GitHub montre le diff : exactement quelles lignes tu as ajoutées (en vert) et supprimées (en rouge).

## Étape 3 : Reviewer une PR (reviewer)

Le reviewer ouvre la PR sur GitHub. Voici les étapes d'une review :

### 1. Lis la description

Tu comprends ce que fait cette PR ? Si non, demande des explications.

### 2. Regarde le diff

Clique sur l'onglet **Files changed**. GitHub montre chaque ligne modifiée. Regarde :

- **Est-ce que le code marche ?** Est-ce que tu le lancerais toi-même si tu le clonais ?
- **Est-ce que le style est cohérent ?** Les mêmes conventions de nommage que le reste du projet ?
- **Est-ce qu'il y a des erreurs ?** Des typos, des imports manquants, des erreurs de logique ?
- **Est-ce qu'il n'y a pas de secrets dedans ?** Des mots de passe, des API keys, des tokens ?
- **Est-ce que c'est compréhensible ?** Quelqu'un qui voit ce code pour la première fois peut-il suivre ce qui se passe ?

### 3. Donne du feedback

Clique sur une ligne pour ajouter un comment. Sois précis :

**Du bon feedback :**
> Dans `groet.py` ligne 2 : que se passe-t-il si `naam` est vide ? Peut-être ajouter une valeur par défaut ?

**Du mauvais feedback :**
> Ce n'est pas bon.

### 4. Envoie ta review

Clique sur **Review changes**. Tu as trois options :

- **Comment** : juste du feedback, pas de décision.
- **Approve** : le code est bon, il peut être mergé.
- **Request changes** : il faut changer quelque chose avant que la PR puisse être mergée.

Pour ta première review : choisis **Approve** si tout a l'air bon, ou **Request changes** si tu veux faire changer quelque chose.

## Étape 4 : Traiter le feedback (auteur)

Le reviewer a laissé un comment. L'auteur modifie le code :

```bash
# Vérifie que tu es bien sur ta branche feature
git switch feature/groet-functie

Modifie groet.py sur base du feedback. Par exemple :

def groet(naam="wereld"):
    return f"Hallo {naam}!"

Committe et pushe :

git add groet.py
git commit -m "Add default parameter to groet function"
git push

Le nouveau commit apparaît automatiquement dans la PR. Le reviewer voit la mise à jour et peut regarder à nouveau.

Étape 5 : Merger et nettoyer

Si le reviewer a mis Approved, il est temps de merger.

Sur GitHub, dans la PR, tu cliques sur Merge pull request. Choisis Create a merge commit (l’option par défaut). Clique sur Confirm merge.

La branche feature est maintenant fusionnée avec master. Sur GitHub, tu peux supprimer la branche avec le bouton Delete branch qui apparaît après le merge.

En local, tu dois aussi nettoyer :

git switch master
git pull                      # récupère le merge qui vient d'avoir lieu sur GitHub
git branch -d feature/groet-functie   # supprime la branche locale

Ton master est maintenant up-to-date. Ta branche feature a disparu, en local et sur GitHub. Prêt pour le prochain morceau de travail.

Le workflow PR complet en un coup d’œil

1. git switch -c feature/iets        ← Crée une branche feature
2. Travaille, committe, travaille, committe
3. git push -u origin feature/iets   ← Push vers GitHub
4. Ouvre une PR sur GitHub           ← Demande une review
5. Le reviewer regarde, donne du feedback
6. Modifie le code, committe, pushe  ← Traite le feedback
7. Le reviewer a approuvé
8. Merge la PR sur GitHub            ← Le code part vers master
9. git switch master && git pull       ← Récupère master en local
10. git branch -d feature/iets       ← Nettoie la branche

Reviewer la PR de quelqu’un d’autre : comment bien faire ?

Une review, ce n’est pas : « Ça a l’air bon. » Une bonne review est précise, constructive et respectueuse.

Les questions que tu te poses pendant une review :

  • Est-ce que je comprends ce que fait ce code ? (Si non : demande de meilleurs comments ou une description plus claire.)
  • Est-ce que le code fait ce que promet la description de la PR ?
  • Est-ce que ça peut être plus simple ?
  • Est-ce qu’il manque quelque chose ? (Gestion des erreurs, edge cases, documentation)
  • Est-ce qu’il y a des secrets, des mots de passe ou des données personnelles dedans ?
  • Est-ce que le code suit le style du reste du projet ?

Comment donner du feedback :

Commence par ce qui est bien. Sois ensuite précis sur ce qui peut être mieux. Termine par une conclusion claire.

Exemple :

La fonction marche exactement comme décrit. Deux suggestions :

  1. À la ligne 2 : une valeur par défaut pour naam serait pratique.
  2. Pense à ajouter une docstring qui explique ce que la fonction retourne.

Pour le reste, ça a l’air bon. Si tu changes ces deux choses, je l’approuve avec plaisir.

Showcase

Échange ton rôle avec ton buddy et refais tout le workflow une fois : maintenant, c’est toi le reviewer.

Montre à un coach :

  1. Une pull request ouverte sur GitHub avec une description.
  2. Au moins un comment de review sur une PR de ton buddy.
  3. Une PR mergée avec succès : le code de la feature est maintenant sur master.

À la prochaine !

C’était la dernière session Git. Ce que tu sais faire maintenant :

  • Gérer les versions de ton code avec Git (init, add, commit, log, diff)
  • Expérimenter sur des branches sans casser master (branch, switch, merge)
  • Partager ton code en ligne via GitHub (push, pull, clone)
  • Écrire des commit messages professionnels
  • Travailler à plusieurs via des pull requests : en ouvrir et en reviewer

Ce n’est pas « en plus ». C’est comme ça que les développeurs travaillent chaque jour. Que tu fasses des jeux, des sites web ou de l’IA : Git et GitHub sont les outils qui gardent ton projet sous contrôle. Utilise-les.

À emporter chez toi

  1. Facile : ouvre une pull request pour une modification dans un de tes propres projets.
  2. Moyen : demande à un ami ou à un membre de ta famille de créer un compte GitHub. Invite-le comme collaborator et laisse-le reviewer une PR.
  3. Difficile : contribue à un vrai projet open source. Cherche sur GitHub des issues avec le label good first issue. Forke le repo, fais un fix et ouvre une PR.
  4. Très difficile : construis un petit projet avec deux autres personnes. Utilise des branches, des pull requests et des reviews. Travaille comme si tu étais dans une équipe professionnelle.