Session 14 : Notes du coach

Objectif de cette session

À la fin de cette session, un ninja sait :

Écrire des commit messages avec un titre (72 caractères max, imperative mood, anglais) + un corps optionnel.
Expliquer pourquoi master doit toujours marcher.
Organiser ses branches avec les préfixes feature/, bugfix/ et experiment/.
Utiliser git stash et git stash pop pour mettre du travail à moitié fini de côté.
Faire git pull par défaut avant git push.
Entretenir un bon .gitignore pour des projets Python.

Préparation (30 min avant la session)

Préparer un repo avec de mauvais commits. Fais un repo de démo avec quelques mauvais commit messages (« fix », « update », « wip »). Utilise-le comme matériel « avant » pour montrer à quel point l’historique devient flou.
Cheatsheet .gitignore prête à imprimer. L’exemple de .gitignore de la session est une bonne fiche de référence. Imprime-le ou écris-le au tableau.
Démo de commit multi-lignes. Montre comment faire un commit message sur plusieurs lignes sans éditeur externe.

Répartition du temps (3 heures)

Temps	Activité
0:00 à 0:10	Rappel des sessions 11 à 13 : commits, branches, GitHub
0:10 à 0:30	Projecteur : mauvais vs. bons commit messages
0:30 à 1:00	En autonomie : réécrire ses propres vieux commits (pas avec rebase ; juste de nouveaux commits avec de meilleurs messages)
1:00 à 1:15	Pause
1:15 à 1:40	Projecteur : stratégie de branching, `.gitignore`, `git stash`
1:40 à 2:30	En autonomie : branches avec préfixes, créer un `.gitignore`, s’exercer avec `git stash`
2:30 à 2:45	Showcase : montre tes commit messages et ta structure de branches
2:45 à 3:00	Cliffhanger, à emporter

Questions fréquentes

« Je dois écrire chaque commit message en anglais ? » Oui. Le code est en anglais. Les variables sont en anglais. Les noms de fonctions sont en anglais. Les commit messages suivent la même langue. Exception : si tu travailles dans une équipe entièrement néerlandophone et que c’est l’accord. Mais pour l’open source et un portfolio : anglais.

« Et si je fais une faute dans mon commit message ? » Tu peux modifier le message de ton dernier commit avec git commit --amend. Ça ouvre un éditeur. Modifie le message, sauvegarde, ferme. Attention : si tu as déjà pushé ce commit vers GitHub, tu dois utiliser git push --force. Ne fais ça que sur des branches que tu es seul à utiliser, jamais sur master ou sur des branches partagées.

« Quand est-ce que j’utilise git stash et quand une branche ? » git stash sert aux interruptions courtes : « Je suis occupé, mais je dois switcher 5 minutes. » Une branche sert à : « C’est un morceau de travail séparé qui demande plusieurs commits. » Règle de base : si tu quittes ton travail en cours pour plus de 10 minutes, fais une branche.

« Comment je sais si master ‘marche’ ? » Lance ton code. S’il tourne sans erreurs et que la fonctionnalité de base fait ce qu’elle doit faire, il marche. Teste ça avant chaque merge vers master. Si tu merges une branche feature et que quelque chose casse sur master, tu dois réparer ça avant de continuer sur autre chose.

Indices pour Stretch et Expert

Stretch : git commit --amend : Modifie le message de ton dernier commit sans faire un nouveau commit. À utiliser seulement en local, pas après un push (sauf avec --force).

Expert : rebase interactif : git rebase -i HEAD~3 te laisse réordonner, fusionner ou renommer tes 3 derniers commits. Puissant, mais ne l’utilise pas sur des branches partagées. C’est la « machine à remonter le temps sous stéroïdes » de Git.

Script du cliffhanger

« Commit messages, branches, .gitignore : ça, c’est ta boîte à outils. Mais il reste une étape entre ta branche feature et master. Dans chaque équipe, dans chaque entreprise, ton code doit passer par une review avant d’être accepté. Une pull request. Toi tu demandes : ‘Est-ce que ça peut entrer ?’ Quelqu’un d’autre regarde, donne du feedback, et c’est seulement là que ton code part vers master. La prochaine fois : comment faire une pull request, et comment reviewer celle d’un autre ? »

Pièges pratiques

Des commit messages au passé. « Added feature » est une faute très courante. Ça paraît naturel parce que tu viens de le faire. Mais Git lui-même décrit les commits au présent : Merge, pas Merged. Entraîne les ninjas à taper « Add », pas « Added ».
Des commits trop gros. Les ninjas veulent souvent « tout committer d’un coup » : tout le travail de la session entière. Encourage-les à faire un commit toutes les 15 minutes. Propose : « Committe maintenant ce que tu as, comme ça tu peux continuer à expérimenter après. »
Oublier de committer le .gitignore. Le .gitignore lui-même doit bien aller dans Git. Sinon, les autres qui clonent ton repo n’ont pas les règles d’ignore. C’est une faute de débutant très courante : le fichier existe en local mais n’a jamais été git add et commité.