Arrêter d'enseigner Git avec des slides

Pendant deux ans, j'ai enseigné Git avec des slides. Des schémas propres, des flèches colorées, des commits alignés comme des perles sur un fil. À la fin de la session, tout le monde hochait la tête. À la première vraie merge gone wrong, plus personne ne savait quoi faire.

J'ai arrêté.

Le problème des slides

Les slides Git créent une illusion de compréhension. Tu vois le modèle de Git, mais tu ne ressens pas la mécanique. Tu sais que git merge crée un commit de merge, mais tu n'as jamais eu la sensation d'un rebase qui rejoue 12 commits sur ta tête.

Pire : les slides présentent Git comme un système cohérent et logique. Or Git n'est ni cohérent ni logique. Git est un outil qui s'est construit en réponse à des problèmes concrets, avec des couches successives. La CLI a des incohérences. La doc est touffue. L'expérience de débutant·e est souvent : « j'ai fait quelque chose, j'ai cassé un truc, je ne sais pas quoi ».

Une formation qui ne reproduit pas cette expérience prépare mal au quotidien réel.

Ce que j'ai mis à la place

Trois piliers.

1. Erreurs volontaires

J'introduis Git en cassant. Premier exercice : « voici un repo, fais ce que je te demande, et observe ce qui se passe ». Le déroulé inclut volontairement :

• Un commit sans add préalable (rien n'arrive)
• Un git reset --hard qui détruit un commit
• Un conflit de merge sur une seule ligne
• Un push refusé parce que origin/main a avancé

À chaque étape, on fait un git status ensemble. On lit la sortie. On comprend ce que Git essaie de nous dire. Cette routine devient le réflexe central : face à n'importe quel problème Git, on commence par status.

2. Vrais workflows

Au lieu de scénarios abstraits, on simule un projet réel à deux. Chacun·e a son repo, on travaille sur la même feature à deux, on pushe à tour de rôle, on ouvre des PR. On voit en direct ce qui se passe quand un·e collègue pousse avant nous.

C'est moins propre qu'une slide. C'est exactement ce qui se passe en équipe.

3. Pair programming sur Git

L'astuce qui change tout : pour les exercices avancés (rebase interactif, cherry-pick, reflog), je mets les apprenant·es en pair, sur une seule machine. Un·e tape, l'autre lit la doc et explique à voix haute ce qui devrait se passer.

Le résultat : ça discute, ça hésite, ça se trompe ensemble. Et ça retient. Bien mieux qu'en solo devant des slides.

Ce que ça a changé

Trois choses observables.

D'abord, les questions posées en classe ont changé. Avant : « c'est quoi un commit ? ». Après : « ma branche est en avance de 3 et en retard de 2, qu'est-ce que je fais ? ». C'est exactement le type de question qu'on se pose en équipe.

Ensuite, les conflits de merge ne génèrent plus de panique. Quelqu'un voit <<<<<<< HEAD apparaître, et au lieu de fuir, ouvre le fichier et résout. Parce qu'il l'a déjà fait en TP.

Enfin, le temps total de formation Git a baissé. On passe de 2 jours à 1 jour et demi pour un meilleur niveau de sortie. Parce qu'on n'enseigne plus au cas où. On enseigne ce qui sert.

L'effort caché

Ce format demande plus de travail côté formateur·ice. Préparer une slide, c'est 30 minutes. Préparer un exercice avec erreurs volontaires, scénarios qui s'enchaînent, points de débriefing, c'est plusieurs heures par session. Et il faut maintenir les exercices vivants, ajuster, débugger en direct.

Mais le retour sur investissement est énorme. Une session bien préparée est réutilisable. Le matériau s'améliore session après session. Et tu peux la transmettre à un·e nouveau·elle formateur·ice avec un bon brief.

Et si tu veux essayer

Tu n'es pas obligé·e de tout casser. Commence par une seule modification : la prochaine fois que tu présentes Git, prépare un repo avec un conflit pré-construit. Demande aux apprenant·es de cloner, de tirer, et de gérer le conflit ensemble. Observe.

Tu verras très vite si tes apprenant·es comprennent Git, ou s'iels ont juste vu Git. La différence est énorme.