Session 15 : Notes du coach

Objectif de cette session

À la fin de cette session, un ninja sait :

• Travailler avec un buddy sur le même repo GitHub (accès collaborator).
• Pusher une branche feature vers GitHub.
• Ouvrir une pull request avec une description structurée (quoi, pourquoi, comment tester).
• Reviewer la PR d’un buddy : lire le diff, donner un feedback précis sur des lignes, approuver ou demander des changements.
• Traiter le feedback en pushant des commits supplémentaires sur la branche feature.
• Merger une PR approuvée et nettoyer la branche (en local et sur GitHub).

C’est la dernière session de la série Git.

Préparation (45 min avant la session)

• Former les duos. Les ninjas travaillent par deux. Décide à l’avance qui travaille avec qui. Tiens compte de : compte GitHub actif ou pas, expérience de Git, âge. Un ninja expérimenté avec un débutant marche souvent bien : le ninja expérimenté apprend en expliquant.
• Check WiFi. Cette session demande un internet stable pour tous les laptops en même temps. Teste avant.
• Préparer un repo de démo. Prépare un repo sur lequel tu peux faire la démo de tout le workflow PR au projecteur : une branche feature, ouvrir une PR, placer un comment, merger une PR.
• Ton propre compte GitHub sous la main. Tu dois pouvoir envoyer et accepter des invitations collaborator pendant la démo.
• Backup : explication du fork de repo. Si l’accès collaborator ne marche pas pour une raison ou une autre (e-mail inaccessible, problèmes de permissions), tu peux expliquer le workflow du fork comme fallback. Voir la section « Pièges pratiques » ci-dessous.

Répartition du temps (3 heures)

Questions fréquentes

« Quelle est la différence entre un collaborator et un fork ? » Collaborator = tu as directement accès en push au repo. Tu travailles sur des branches dans le même repo. Fork = tu fais une copie du repo de quelqu’un vers ton compte. Tu travailles dans ta copie, et tu ouvres une PR de ton fork vers l’original. Collaborator est plus facile pour les débutants ; le fork, c’est comme ça que marche l’open source.

« Mon buddy n’arrive pas à accepter mon invitation. » Vérifie : le reviewer a-t-il accès à son e-mail ? GitHub envoie l’invitation par e-mail. Alternative : le reviewer peut aller sur https://github.com/AUTEUR_USERNAME/repo-naam/invitations pour accepter l’invitation directement.

« Je dois merger chaque PR avec un merge-commit ? » GitHub donne trois options : merge commit, squash merge, rebase merge. Pour l’instant : utilise l’option par défaut (merge commit). Elle garde tout l’historique de ta branche feature. Squash et rebase sont plus avancés et tu les verras plus tard.

« Et si je travaille par accident sur la mauvaise branche ? » Vérifie toujours avec git status sur quelle branche tu es avant de commencer. Si tu as déjà fait des commits sur la mauvaise branche : git stash tes modifications, switch sur la bonne branche, et git stash pop.

« Je peux annuler une PR après l’avoir mergée ? » Tu peux annuler un commit avec git revert <commit-hash>. Ça crée un nouveau commit qui annule les modifications. C’est plus sûr que de réécrire l’historique, surtout sur master.

Indices pour Stretch et Expert

Stretch : template de PR : GitHub peut montrer un template chaque fois que quelqu’un ouvre une PR. Crée un fichier .github/pull_request_template.md dans ton repo avec dedans :

## Quoi

## Pourquoi

## Comment tester

GitHub le remplit automatiquement à chaque nouvelle PR.

Expert : Draft PR : Si tu veux ouvrir une PR tôt pour du feedback, même si le code n’est pas encore fini, fais une draft PR. Clique sur la flèche à côté de « Create pull request » → « Create draft pull request ». Les draft PR ne peuvent pas être mergées par accident.

Expert : review de plusieurs commits : Dans l’onglet « Files changed », tu peux regarder commit par commit ce qui a changé. Clique sur le dropdown des commits au-dessus du diff. C’est pratique quand une PR a plusieurs commits et que tu veux les regarder un par un.

Récapitulatif : retour sur toute la série

À la fin de cette session, tu peux faire un petit retour sur ce que les ninjas ont appris en cinq sessions :

C’est la boîte à outils de chaque développeur professionnel. Les ninjas n’ont pas besoin de tout maîtriser parfaitement, mais ils doivent savoir que ça existe, et savoir appliquer la base eux-mêmes.

Pièges pratiques

1. L’accès collaborator ne marche pas. Solution : utilise le workflow du fork comme fallback. Le reviewer forke le repo de l’auteur, clone le fork, crée une branche, et ouvre une PR du fork vers l’original. Ça ne demande pas d’accès collaborator. C’est un peu plus complexe, mais utile à connaître.

2. Des merge conflicts pendant la PR. Si master a changé depuis que la branche feature a été créée, un merge conflict apparaît au moment de merger la PR. GitHub affiche un avertissement. L’auteur doit merger master en local dans la branche feature, résoudre le conflict, et pusher à nouveau. Aide les ninjas ici ; des merge conflicts dans un contexte de PR sont plus déroutants que des conflicts locaux.

3. Des PR trop grosses. Une PR qui modifie 30 fichiers est difficile à reviewer. Encourage les ninjas à garder les PR petites : une feature, une PR. Si une feature est trop grosse, découpe-la en plusieurs PR plus petites.

4. Oublier de puller après le merge. Après le merge sur GitHub, l’auteur doit faire git pull en local sur master. Sinon il travaillera bientôt sur un master dépassé et des problèmes apparaîtront à la branche suivante.