Session 11 : Notes du coach

Objectif de cette session

À la fin de cette session, un ninja sait :

Expliquer ce qu’est la gestion de versions et pourquoi on l’utilise.
Installer Git sur son propre laptop et configurer git config.
Créer un dépôt avec git init.
Ajouter des fichiers avec git add et les committer avec git commit -m.
Utiliser git status, git diff, git log --oneline et git show pour inspecter les modifications.
Créer un fichier .gitignore et comprendre pourquoi il existe.

Ce qui n’est pas attendu : les branches, GitHub, les pull requests. Ça vient dans les sessions 12 à 15.

Préparation (30 min avant la session)

Vérifier Git Bash sur les laptops Windows. Beaucoup de laptops Windows n’ont pas Git. Assure-toi que les installateurs sont prêts sur une clé USB, ou partage le lien de téléchargement (git-scm.com). L’installation prend ~5 minutes.
Estimer la peur du terminal. Beaucoup de ninjas n’ont jamais ouvert un terminal. Les 15 premières minutes servent à expliquer : c’est quoi un terminal, comment on tape des commandes, ce que fait Enter.
Parcourir la session toi-même. Crée un dépôt, committe quelques fichiers, fais un git diff, un git log. Assure-toi de passer les étapes sans faute pour pouvoir aider tes ninjas.
Projecteur prêt pour les démos de terminal. Mets le terminal en grande police (Ctrl+Plus dans la plupart des terminaux). Les ninjas doivent pouvoir lire les commandes depuis leur place.

⚠️ Risque : le terminal est nouveau pour beaucoup

Pour beaucoup de ninjas (surtout de 10 à 12 ans), le terminal est complètement nouveau. L’interface en ligne de commande n’est pas visuelle, et les messages d’erreur sont en anglais.

Mitigations :

Fais d’abord toutes les démos sur le projecteur. Tape chaque commande et explique ce qui se passe. Ne les laisse pas commencer avant d’avoir fait les deux premières étapes toi-même.
Imprime la cheatsheet ou écris-la au tableau. Les commandes les plus utilisées (git status, git add, git commit, git log) doivent rester visibles.
Les fautes de frappe, c’est normal. Explique que le terminal est extrêmement précis : git Status (avec majuscule) ne marche pas, git status (en minuscules) oui. Une espace de trop ou de moins peut donner une erreur.
git commit sans -m ouvre un éditeur. Si un ninja tape git commit sans -m, Vim ou Nano s’ouvre. Apprends-leur : Escape, puis :q! et Enter pour s’en sortir. Ensuite, on recommence avec -m.

Répartition du temps (3 heures)

Temps	Activité
0:00 à 0:15	Accueil, c’est quoi Git ? Analogie : un bouton save, mais avec l’historique
0:15 à 0:30	Projecteur : installer Git + `git config`
0:30 à 1:15	En autonomie : `git init`, premier fichier, `git add`, `git commit`
1:15 à 1:30	Pause
1:30 à 2:00	Projecteur : `git diff`, `git log`, `git show`. Démo : retour dans le temps
2:00 à 2:30	En autonomie : faire des modifications, lire des diffs, construire des commits
2:30 à 2:45	Expliquer et appliquer `.gitignore`
2:45 à 3:00	Showcase, cliffhanger, à emporter

Questions fréquentes

« Je dois faire git add pour chaque fichier séparément ? » Oui, au début. Plus tard tu peux utiliser git add . pour ajouter tous les fichiers modifiés d’un coup. Mais apprends d’abord le contrôle fichier par fichier, ça évite de committer par accident des choses qui ne doivent pas être dans Git.

« Et si je committe un mot de passe par accident ? » Pas de panique. Si c’est en local (pas encore envoyé sur GitHub), tu peux le corriger. Si tu l’as déjà pushé sur GitHub : change le mot de passe tout de suite. Supprimer un commit de l’historique GitHub est presque impossible. C’est exactement pour ça qu’on utilise .gitignore.

« Git dit ‘fatal: not a git repository’ » Tu n’es pas dans le bon dossier. Utilise cd pour aller dans ton dossier de projet. Vérifie avec ls si tu vois le dossier .git (il est caché, donc ls -a pour le voir).

« Quelle est la différence entre git add et git commit ? » git add = « Je veux garder ces modifications. » git commit = « Garde-les maintenant, avec cette étiquette. » Tu peux faire plusieurs git add et ensuite un seul git commit qui prend tout ensemble. La staging area, c’est ton panier de courses : tu y mets des choses avec add, et à la caisse (commit) tu paies tout d’un coup.

Indices pour Stretch et Expert

Donne des indices, pas des commandes complètes.

Stretch : plusieurs fichiers à la fois : Si tu as modifié trois fichiers, tu peux les git add un par un, ou d’un coup avec git add . (le point = le dossier actuel + tout ce qu’il contient).

Expert : retour dans le temps avec git checkout : git checkout <commit-hash> -- <nom-du-fichier> remet un fichier dans l’état où il était dans ce commit. Le reste de ton projet ne bouge pas. Pratique si tu as abîmé un seul fichier.

Script du cliffhanger

Lis ceci au groupe à la fin de la session :

« Maintenant tu as une seule ligne de commits. Tout bien à la suite. Mais si tu veux essayer une nouvelle idée sans casser ton code qui marche ? Et si deux personnes travaillent en même temps sur le même projet ? La prochaine fois, on coupe notre code en univers parallèles. Ça s’appelle des branches. Amène ton laptop, on part voyager dans le temps. »

Pourquoi cette session maintenant ?

Jusqu’ici, les ninjas travaillaient sur des projets sur un seul ordinateur, avec une seule version. Si quelque chose cassait, il n’y avait pas de retour en arrière (à part « Ctrl+Z jusqu’à hier »).

Cette session introduit l’infrastructure de base que les développeurs professionnels utilisent tous les jours. Ce n’est pas une session Python, c’est une session outillage. Le but n’est pas qu’ils maîtrisent Git parfaitement, mais qu’ils :

Comprennent que la gestion de versions existe.
Connaissent la terminologie de base (repo, commit, staging, log).
Puissent démarrer un repo eux-mêmes et faire des commits.

Ça leur donne une base pour les sessions 12 à 15, et pour tout le travail de programmation qu’ils feront après.

Important : ne force pas la perfection. Tant qu’un ninja sait faire git init, git add, git commit et qu’il comprend git status, la session est réussie.