Session 12 : Notes du coach
Objectif de cette session
À la fin de cette session, un ninja sait :
- Expliquer ce qu’est une branche et pourquoi on en utiliserait une.
- Créer une branche (
git branch/git switch -c), y aller, et revenir surmaster. - Faire des commits sur une branche sans toucher à
master. - Merger une branche dans
masteravecgit merge. - Reconnaître et résoudre un merge conflict simple.
- Supprimer une branche devenue inutile avec
git branch -d.
Ce qui n’est pas attendu : les branches distantes, les pull requests, l’intégration GitHub. Ça vient dans les sessions 13 à 15.
Préparation (30 min avant la session)
- Repo prêt sur le projecteur. Utilise le projet de la session 11 ou fais un repo de démo avec 2 à 3 commits sur
master. Tu dois pouvoir switcher, brancher et merger pendant la démo. - Préparer le merge conflict. La démo de merge conflict (Étape 5) est la partie la plus difficile. Parcours-la deux fois toi-même. Le visuel de
<<<<<<< HEADet=======doit pouvoir s’expliquer clairement. - Terminal sur le projecteur en grande police. CTRL+Plus pour être sûr.
Répartition du temps (3 heures)
| Temps | Activité |
|---|---|
| 0:00 à 0:10 | Rappel de la session 11 : commits, log, status. C’était quoi déjà ? |
| 0:10 à 0:30 | Projecteur : c’est quoi une branche ? Démo : créer une branche, switcher, voir les fichiers disparaître |
| 0:30 à 1:00 | En autonomie : créer une branche, ajouter des fichiers, switcher, merger |
| 1:00 à 1:15 | Pause |
| 1:15 à 1:45 | Projecteur : les merge conflicts. C’est quoi, à quoi ça ressemble, comment les résoudre ? |
| 1:45 à 2:30 | En autonomie : créer et résoudre des merge conflicts, ranger les branches |
| 2:30 à 2:45 | Showcase : montre tes branches, ton log et un conflit résolu |
| 2:45 à 3:00 | Cliffhanger, à emporter |
Questions fréquentes
« Pourquoi la branche principale s’appelle master ? »
Dans nos sessions, la branche principale s’appelle master. C’était le standard dans Git pendant des années. Depuis 2020, GitHub utilise main par défaut, un mot plus neutre. Beaucoup de nouveaux projets utilisent main, les plus anciens master. Même concept, autre nom. Dans ce cours, on reste sur master, mais si tu croises main en ligne : c’est exactement la même chose.
« Je dois faire chaque modification sur une branche séparée ? »
Non. Les petites corrections (fautes de frappe, commentaires), tu peux les faire directement sur master. Les branches servent pour les choses qui demandent plusieurs commits ou qui sont risquées.
« Comment je sais sur quelle branche je suis ? »
git status l’affiche en haut. git branch montre toutes les branches avec une astérisque à côté de la branche active. Prends l’habitude de vérifier ça avant de commencer à travailler, pour éviter d’écrire du code sur la mauvaise branche.
« J’ai perdu mes commits après le switch ! » Tes commits ne sont pas perdus : ils sont sur l’autre branche. Reviens dessus et ils sont là. C’est exactement le but : les branches isolent le travail les unes des autres.
« Git dit ‘Already up to date’ quand je merge »
Ça veut dire qu’il n’y a rien à merger, parce que la branche que tu essaies de merger n’a pas de nouveaux commits. Vérifie avec git log si tu as bien fait des commits sur la bonne branche.
Expliquer les merge conflicts (visuel)
C’est le concept le plus difficile de la session. Utilise une analogie :
« Imagine : toi et ton copain, vous faites tous les deux le même devoir. Toi, tu as répondu à la question 3 par ‘42’. Ton copain a écrit ‘37’. Le prof reçoit les deux versions et dit : ‘Je ne sais pas quelle est la bonne réponse. Vous devez chercher ensemble.’
<<<<<<< HEAD, c’est ta version.=======est la ligne de séparation.>>>>>>> andere-branch, c’est la version de ton copain. Git dit : ‘Voilà les deux réponses, choisis.’ Tu enlèves les marqueurs et tu choisis la bonne réponse. Puisgit addetgit commit, et c’est fini. »
Montre les marqueurs littéralement sur le projecteur. Ça a l’air effrayant (<<<<<<<, >>>>>>>, =======) mais c’est juste un menu de choix.
Indices pour Stretch et Expert
Stretch : git log --graph :
git log --graph --oneline --all montre un arbre visuel de tes branches. Pratique quand tu ne sais plus comment les branches s’emboîtent.
Expert : écraser une branche avec git merge :
Si tu fais git merge feature-branch alors que master n’a pas de nouveaux commits depuis que la branche s’est séparée, Git fait un fast-forward : il déplace simplement le pointeur master vers le dernier commit de la branche feature. Pas besoin de merge-commit. Si master a bien de nouveaux commits, Git crée un vrai merge-commit.
Script du cliffhanger
« Maintenant tu peux avoir deux versions de ton code en même temps. Mais tout est encore seulement sur ton laptop. La prochaine fois, ton code part dans le vaste monde. On crée un compte GitHub, on met ton dépôt en ligne, et, le plus cool, on récupère du code d’autres personnes. Ton jeu. En ligne. Pour tout le monde. »
Pourquoi cette session maintenant ?
La session 11 a donné aux ninjas une seule ligne du temps. Cette session leur apprend à séparer et à fusionner. C’est le concept central de Git : le développement non linéaire.
Sans branches :
- Tu n’oses pas prendre de risques avec ton code.
- Collaborer est impossible.
- Tu ne peux pas revenir à une version précédente sans perdre ton travail actuel.
Avec des branches :
- Expérimenter est sans danger.
- Tu peux travailler sur plusieurs choses en même temps.
- Collaborer devient possible (les sessions 13 à 15 construisent là-dessus).