Session 13 : Notes du coach

Objectif de cette session

À la fin de cette session, un ninja sait :

Créer un compte GitHub et se connecter.
Créer un nouveau dépôt sur GitHub.
Relier un projet local à GitHub avec git remote add origin.
Pusher du code vers GitHub avec git push -u origin master (et ensuite git push).
Cloner un repo GitHub existant sur le laptop avec git clone.
Récupérer des modifications avec git pull.

Ce qui n’est pas attendu : les pull requests, les forks, les GitHub Actions, les issues. Ça vient dans les sessions 14 à 15.

Préparation (30 min avant la session)

Check WiFi. C’est la première session qui demande internet. Teste la connexion sur le lieu du dojo. Au moins 10 laptops en même temps sur le WiFi. Si la connexion est lente, fais travailler les ninjas par groupes de 2 à 3 avec un seul compte GitHub.
Compte GitHub prêt. Crée-toi un compte de test si tu n’en as pas encore, ou utilise ton compte existant. Tu dois pouvoir faire des démos.
Accès e-mail. Vérifie que les ninjas peuvent accéder à leur e-mail. GitHub demande une vérification par e-mail. Si un ninja n’a pas accès à son e-mail : la vérification peut se faire plus tard. Il peut faire le reste de la session normalement ; seules certaines actions (comme créer une organisation) demandent une vérification.
Expliquer la méthode d’authentification. GitHub n’utilise plus de mots de passe dans le terminal. Explique les deux méthodes (authentification par navigateur et Personal Access Token ; voir l’étape 3 de la session).

Répartition du temps (3 heures)

Temps	Activité
0:00 à 0:10	Rappel des sessions 11 et 12 : commits, branches. Qu’est-ce qui est en local ?
0:10 à 0:25	Projecteur : c’est quoi GitHub ? Démo : explorer github.com
0:25 à 0:50	Créer les comptes (tout le monde en même temps ; c’est ce qui prend le plus de temps)
0:50 à 1:15	Projecteur : nouveau repo sur GitHub, `git remote add`, `git push`
1:15 à 1:30	Pause
1:30 à 2:00	En autonomie : pusher un projet existant vers GitHub
2:00 à 2:20	Projecteur : `git clone` : ramener un repo de GitHub sur ton laptop
2:20 à 2:45	En autonomie : cloner, modifier, pusher, puller
2:45 à 3:00	Showcase, cliffhanger, à emporter

Questions fréquentes

« Je dois payer pour GitHub ? » Non. L’abonnement gratuit te donne des repos publics et privés illimités. Tu paies seulement pour les features d’équipe avancées. Pour tout ce qu’on fait, le gratuit suffit.

« Quelle est la différence entre Public et Private ? » Public = tout le monde sur internet peut voir ton code. Private = seulement toi (et les personnes que tu invites). Pour les projets CoderDojo, public est très bien : tu construis ton portfolio. Mais si tu fais un jour un projet avec des mots de passe ou des données personnelles, mets-le en private.

« GitHub demande un mot de passe dans le terminal, mais mon mot de passe ne marche pas ! » Depuis 2021, GitHub n’accepte plus les mots de passe via le terminal. Tu dois soit te connecter via le navigateur (GitHub ouvre une fenêtre), soit utiliser un Personal Access Token. Voir l’étape 3 de la session.

« Je reçois ‘Permission denied’ avec git push » La plupart du temps, ça veut dire : tu essaies de pusher vers un repo qui n’est pas le tien, ou ton authentification a expiré. Vérifie : es-tu dans le bon dossier ? La remote est-elle correcte ? (git remote -v). Essaie de te reconnecter.

« Et si je pushe un mot de passe ou une clé API par accident ? » Arrête tout de suite. Change le mot de passe ou la clé immédiatement. Ensuite : cherche « BFG Repo-Cleaner » ou « git filter-branch » sur Google pour le retirer de l’historique. Mais retiens : si quelqu’un a déjà cloné ton repo, il a encore le mot de passe. La vraie solution, c’est de ne jamais mettre de mots de passe dans Git. Utilise .gitignore et des environment variables.

Indices pour Stretch et Expert

Stretch : plusieurs remotes : Tu peux ajouter plusieurs remotes : git remote add backup https://gitlab.com/.... Pratique pour des sauvegardes supplémentaires. Utilise git remote -v pour les voir.

Expert : git push sans -u : Le premier push a besoin de -u origin master pour définir la branche upstream. Ensuite Git retient le lien et git push suffit. Si tu pushes depuis une autre branche que master, fais git push -u origin branch-naam la première fois.

Script du cliffhanger

« Ton code est en ligne. Mais si tu collabores avec quelqu’un d’autre ? Comment faire pour que ton code ne se percute pas avec celui d’un autre ? Comment demander poliment : ‘Est-ce que cette modification peut entrer dans le projet principal ?’ La prochaine fois : les pull requests, la porte d’entrée de tout projet logiciel professionnel. »

Pièges pratiques

Créer un compte GitHub prend plus de temps que tu ne le penses. Vérification par e-mail, choisir un nom d’utilisateur, dérouler le welcome-flow : compte 10 à 15 minutes par ninja. Fais-le faire en même temps et circule pour aider.
Fautes de frappe dans les usernames. git remote add origin https://github.com/JOUW_USERNAME/repo.git : une seule faute et la remote ne marche pas. Vérifie les URLs deux fois avant qu’ils pushent.
Sensibilité à la casse. github.com/JOUW_USERNAME n’est pas la même chose que github.com/jouw_username. Les usernames GitHub ne sont pas sensibles à la casse, mais c’est une bonne habitude de copier exactement ce que GitHub affiche.
Le premier push peut être lent. Selon la connexion internet, le premier push peut prendre de quelques secondes à une minute. Préviens les ninjas qu’ils ne doivent pas paniquer si le terminal a l’air de « bloquer » un instant.