Session 11 : Git : le livre d'histoire de ton code

Imagine : tu travailles trois heures sur ton jeu. Tu ajoutes une arme trop cool. Mais… maintenant le reste de ton jeu ne marche plus. Et tu ne sais plus ce que tu as changé exactement. Trois heures de travail perdues.

Git est la solution. Git se souvient de chaque version de tes fichiers. Comme un bouton « annuler » infini qui n’oublie jamais ce que tu as fait.

Dans cette session, tu installes Git, tu crées ton premier dépôt et tu enregistres pour toujours ce que tu fais : étape par étape, version par version. Et le plus chouette : Git ne sert pas qu’au code. Il marche aussi pour tes notes, tes travaux d’école et tes histoires.

Qu’est-ce que Git ?

Git est un système de gestion de versions. Il garde une trace de ce que tu changes dans tes fichiers, quand tu l’as fait, et pourquoi. Chaque fois que tu as fini un morceau de travail, tu fais un commit : une photo de tous tes fichiers à ce moment-là.

Ce qui rend Git spécial :

• Chaque version est conservée. Tu peux toujours revenir à un commit précédent si quelque chose casse.
• Tu travailles en local. Git tourne sur ton ordinateur. Pas besoin d’internet.
• Git est rapide. Même des projets avec des milliers de fichiers se vérifient en millisecondes.

Git a été créé par Linus Torvalds, la même personne qui a construit Linux. Il avait besoin d’un outil pour travailler sur le noyau Linux avec des milliers de programmeurs en même temps. En 2005, il a construit Git en un week-end. Aujourd’hui, presque tous les développeurs du monde l’utilisent.

Git ne sert pas qu’au code

Git a été conçu pour le code source, mais il fonctionne avec tous les fichiers texte. Un fichier texte, c’est n’importe quel fichier que tu peux ouvrir et lire avec le Bloc-notes ou un éditeur simple : .py, .html, .css, .json, .txt, .csv, .md (Markdown), .yml, .toml, tout ce que tu veux.

Ce que Git ne sait pas bien faire : les fichiers binaires. Ce sont des fichiers qui ne sont pas du texte lisible : des images (.png, .jpg), des vidéos (.mp4), des programmes compilés (.exe), des documents Word (.docx). Git peut les suivre, mais c’est plus lent et tu ne vois pas ce qui a changé exactement. Avec un fichier texte, git diff montre chaque lettre que tu as ajoutée ou enlevée. Avec un .png, Git dit seulement « ce fichier a changé », mais pas ce qui a changé dans l’image.

Markdown et notes

Beaucoup d’applications de notes d’aujourd’hui utilisent Markdown (des fichiers .md) pour stocker tes documents. Par exemple :

• Obsidian : tes notes sont juste des fichiers .md dans un dossier de ton ordinateur
• Notion : exporte vers Markdown
• Joplin : enregistre tout en Markdown
• Typora, Zettlr, Logseq : tous basés sur Markdown

Comme les fichiers Markdown sont de simples fichiers texte, tu peux les mettre sous Git. Tu gardes l’historique de tes notes, tu peux revenir à une version précédente d’un document, et tu peux partager tes notes via GitHub, exactement comme tu le fais avec du code.

Mettre un dossier de notes Markdown sous Git est aussi simple qu’un projet Python :

mkdir mijn-notities
cd mijn-notities
git init
echo "# Mes notes" > start.md
git add start.md
git commit -m "Première note : page de départ"

À partir de ce moment, Git garde chaque modification de tes notes. Tu écris un travail pour l’école en Markdown ? Commit chaque paragraphe. Tu travailles à la construction d’un monde pour une histoire ? Git retient chaque version de ton intrigue.

Quand utiliser Git pour tes notes, et quand pas

En résumé : tout ce qui est du texte peut aller dans Git. Tout ce qui est binaire, mieux vaut éviter.

Pourquoi la gestion de versions ?

Sans Git, ton workflow ressemble à ça :

game.py
game_backup.py
game_backup2.py
game_final.py
game_final_echt.py
game_final_echt_nieuwe_wapens.py

Tu reconnais ? Avec Git, tu n’as besoin que d’un seul fichier : game.py. Git se souvient du reste.

Ce que la gestion de versions t’apporte :

• Plus jamais de travail perdu. Tout ce que tu commites reste. Pour toujours.
• Comprendre ce qui s’est passé. Tu vois exactement quelles lignes tu as changées et quand.
• Expérimenter sans risque. Tu fais une copie séparée de ton code (une branche), tu essaies un truc bizarre, et tu la jettes si ça ne marche pas. Ton code d’origine reste intact.
• Collaborer. Plusieurs personnes peuvent travailler en même temps sur le même projet, sans écraser le code des autres.

Qu’est-ce que tu ne mets PAS dans Git ?

Git est fait pour les fichiers texte : les fichiers que tu écris toi-même : code, notes, configuration. Il y a des choses que tu gardes mieux en dehors de Git :

Pourquoi pas de mots de passe dans Git ? Parce que Git se souvient de tout, pour toujours. Même si tu supprimes un mot de passe plus tard, il est encore dans l’historique. Quiconque voit ton code un jour peut remonter jusqu’à ce commit. Et si ton code arrive un jour sur GitHub, ton mot de passe est sur internet. Pour l’éternité.

Utilise un fichier .gitignore pour dire à Git quels fichiers il doit ignorer. Tu vas voir ça tout de suite.

Étape 0 : Installer Git

Windows

1. Va sur git-scm.com et télécharge l’installateur Windows.
2. Double-clique sur le fichier téléchargé.
3. Clique à travers l’installation. Les options par défaut sont très bien.
4. Important : au choix de l’éditeur de texte, choisis Nano ou Notepad++ (pas Vim, sauf si tu connais déjà Vim).
5. Après l’installation, ouvre Git Bash (cherche-le dans le menu démarrer).

Mac

Ouvre le Terminal (cherche « Terminal » dans Spotlight) et tape :

git --version

Si Git n’est pas installé, macOS te demande d’installer les developer tools. Clique sur « Install ». C’est fait.

Linux (Ubuntu/Debian)

sudo apt install git

Vérifier que ça marche

Ouvre un terminal (Git Bash sous Windows) et tape :

git --version

Tu vois quelque chose comme git version 2.47.0. Ça veut dire : Git est prêt.

Étape 1 : Dis à Git qui tu es

Git veut savoir qui tu es, pour pouvoir mettre ton nom sur chaque commit. Tu fais ça une seule fois, ensuite Git s’en souvient.

git config --global user.name "Ton Nom"
git config --global user.email "ton@email.com"

Utilise la même adresse e-mail que celle que tu utiliseras tout à l’heure pour GitHub. Ça rend le couplage plus simple.

Astuce : --global veut dire : ce réglage vaut pour tous tes projets Git. Tu ne dois le faire qu’une seule fois.

Étape 2 : Créer ton premier dépôt

Un dépôt (ou « repo ») est un dossier où Git garde les versions. On en crée un.

Crée d’abord un nouveau dossier pour ton projet :

mkdir mijn-eerste-git-project
cd mijn-eerste-git-project

Maintenant tu dis à Git : « Ce dossier est un dépôt. »

git init

Tu vois : Initialized empty Git repository in .../mijn-eerste-git-project/.git/

Git a créé un dossier caché .git. C’est là qu’il garde tout : l’historique, les commits, la configuration. Ne touche jamais ce dossier à la main, c’est Git qui le gère.

Étape 3 : Committer ton premier fichier

Crée un fichier. Par exemple un fichier Python avec une seule ligne :

echo 'print("Salut Git !")' > hallo.py

Maintenant tu dis à Git : « Fais attention à ce fichier. »

git add hallo.py

Avec git add, tu mets des fichiers dans la staging area : une zone intermédiaire. Tu dis à Git : « Ces changements, je veux les mettre dans mon prochain commit. »

Vérifie ce qui est prêt :

git status

Git affiche :

On branch master
Changes to be committed:
  new file:   hallo.py

Maintenant vient le commit lui-même :

git commit -m "Mon premier commit : hallo.py ajouté"

Que se passe-t-il ici ? -m veut dire « message ». Le texte entre guillemets est ton commit message : une courte explication de ce que tu as changé. Git a maintenant pris une photo permanente de ton projet.

Des bons commit messages : écris en anglais (c’est la convention dans presque tous les projets). Commence par un verbe : « Add », « Fix », « Update ». Reste court : 72 caractères maximum.

Étape 4 : Suivre les changements

Ouvre hallo.py dans un éditeur de texte. Change la ligne par :

print("Salut Git ! Tu te souviens de mon code.")

Enregistre le fichier. Regarde maintenant ce que Git voit :

git status

Git sait que hallo.py a changé. Mais qu’est-ce qui a changé exactement ?

git diff

git diff montre exactement quelles lignes tu as ajoutées (en vert avec +) et supprimées (en rouge avec -). C’est une des choses les plus puissantes de Git : tu vois littéralement ce qui a changé, caractère par caractère, depuis ton dernier commit.

Committe la modification :

git add hallo.py
git commit -m "Update : salutation étendue"

Étape 5 : Retour dans le temps

C’est ici que Git devient magique. Imagine : tu regrettes ta dernière modification. Tu veux revenir à la première version.

Montre d’abord tous les commits :

git log --oneline

Tu vois quelque chose comme :

a1b2c3d Update : salutation étendue
e4f5g6h Mon premier commit : hallo.py ajouté

Chaque commit a un code unique, un hash. Ce long code (raccourci à 7 caractères) identifie exactement cette version-là de ton projet.

Pour voir à quoi ressemblait hallo.py dans le premier commit :

git show e4f5g6h:hallo.py

Voilà ton print("Salut Git !") d’origine.

Tu veux vraiment retourner dans le temps ? C’est possible :

git checkout e4f5g6h -- hallo.py

Maintenant hallo.py est de nouveau comme dans ton premier commit. Vérifie avec cat hallo.py. Tu vois l’ancienne version. Mais ne t’inquiète pas : ton deuxième commit n’a pas disparu. Avec git checkout master -- hallo.py, tu reviens à la dernière version.

Étape 6 : Ce qui ne va pas dans Git : .gitignore

Crée un fichier que Git doit ignorer :

echo "GEHEIM_WACHTWOORD=12345" > geheimen.txt

git status montre maintenant ce fichier comme « untracked ». Git l’a vu, mais il ne sait pas si tu veux le suivre. Tu peux l’ignorer avec un fichier .gitignore :

echo "geheimen.txt" > .gitignore

Maintenant git status à nouveau et geheimen.txt a disparu de la liste. Git l’ignore. (Ajoute bien .gitignore lui-même à Git avec git add .gitignore et git commit, pour que les autres sachent aussi ce qu’il faut ignorer.)

Un bon .gitignore pour un projet Python :

# Python
__pycache__/
*.pyc
*.pyo

# Secrets
*.env
secrets.txt

# Ton éditeur
.vscode/
.idea/

Showcase

Montre à un coach et à un buddy :

1. Ton dépôt avec au moins 3 commits.
2. Le résultat de git log --oneline : ton historique de commits.
3. Un git diff qui montre ce que tu as changé.
4. Ton fichier .gitignore.

À la prochaine !

« La prochaine fois : deux versions de ton code en même temps. Tu travailles sur une nouvelle feature pendant que l’ancienne version continue de marcher. Ça s’appelle des branches, et c’est ce qui rend Git vraiment puissant. »

À emporter chez toi

1. Facile : crée un dépôt pour tes notes. Mets un fichier Markdown avec ce que tu as appris aujourd’hui dans Git, et committe-le.
2. Moyen : change quelque chose dans ton code ou tes notes, utilise git diff pour regarder la modification, et committe-la avec un bon message.
3. Difficile : fais trois commits avec des modifications différentes. Utilise git show pour regarder chaque version. Utilise git checkout pour revenir au premier commit, puis de nouveau au dernier.
4. Très difficile : fais un projet Python avec un bon .gitignore. Fais en sorte que __pycache__/ et les fichiers .pyc soient vraiment ignorés (vérifie avec git status).

Bloqué ? Demande au dojo suivant à un coach, ou essaie simplement autre chose. Programmer, c’est faire. Apprendre Git, c’est faire.

Session 12 : Git Branches : des univers parallèles pour ton code

La session précédente, tu as appris à faire des commits : des photos de ton code sur une seule ligne du temps. Tout bien à la suite.

Mais si tu veux essayer une nouvelle idée ? Ajouter un pistolet laser à ton jeu, par exemple. Tu ne sais pas si ça va marcher. Tu ne veux pas casser ton code qui fonctionne.

C’est pour ça que les branches existent.

Une branche est une copie de ton code où tu peux expérimenter librement. Ton code principal (la branche master) reste en sécurité. Si ton expérience marche, tu la recolles dans master. Si elle ne marche pas ? Tu jettes la branche. Ta branche master n’en a jamais rien su.

Note : sur GitHub et dans beaucoup de nouveaux projets, la branche principale s’appelle main au lieu de master. C’est exactement la même chose, seul le nom change. Dans ce cours, on utilise master, mais si tu croises main en ligne, tu sais que ça veut dire la même chose.

Ce que tu vas apprendre aujourd’hui

• Ce qu’est une branche et comment Git stocke les branches en interne
• Créer, changer et fusionner des branches
• Ce qu’est un merge conflict et comment le résoudre
• Quand utiliser une branche, et quand pas

Étape 0 : Rappel : où en es-tu ?

Ouvre ton terminal dans le projet de la session précédente. Vérifie où tu es :

git status
git log --oneline

Tu as quelques commits sur master. C’est ta base stable : c’est d’ici que tu vas te séparer tout à l’heure.

Étape 1 : Ta première branche

Tu vas ajouter une nouvelle feature : un fichier highscore.txt qui garde le meilleur score. Mais d’abord, tu crées une branche :

git branch highscore-feature

Git a maintenant créé une nouvelle branche. Mais tu es toujours sur master. Vérifie quelles branches existent :

git branch

Tu vois :

  highscore-feature
* master

L’astérisque à côté de master veut dire : « tu es ici ». Passe à ta nouvelle branche :

git switch highscore-feature

(Les versions plus anciennes de Git utilisent git checkout highscore-feature. Les deux marchent.)

Encore une fois git branch : l’astérisque est maintenant à côté de highscore-feature. Tout ce que tu commites maintenant se passe sur cette branche. master reste intact.

Astuce : tu peux créer une branche et y aller directement en une seule commande :

git switch -c mijn-nieuwe-branch

-c veut dire « create ». C’est plus rapide et tu n’oublies jamais de changer de branche.

Étape 2 : Travailler sur une branche

Crée un nouveau fichier :

echo "HIGHSCORE: 0" > highscore.txt

Committe ton travail :

git add highscore.txt
git commit -m "Add highscore.txt avec valeur de départ 0"

Ajoute encore un fichier qui lit le highscore :

echo 'def lees_highscore():' > highscore_manager.py
echo '    with open("highscore.txt") as f:' >> highscore_manager.py
echo '        return int(f.read().split(": ")[1])' >> highscore_manager.py

Committe encore :

git add highscore_manager.py
git commit -m "Add highscore_manager : fonction pour lire le highscore"

Regarde maintenant ton log :

git log --oneline

Tu vois tous tes commits de master, plus les deux nouveaux. Git se souvient de toute la chaîne.

Étape 3 : Deux mondes en même temps

Reviens sur master :

git switch master

Regarde ce qu’il y a ici :

ls

highscore.txt et highscore_manager.py ont… disparu. Ils existent seulement sur la branche highscore-feature. Sur master, tout est encore exactement comme tu l’as laissé.

C’est la magie des branches : deux (ou plus) versions de ton projet, en même temps sur ton ordinateur, sans se gêner.

Change encore une fois dans les deux sens pour le sentir :

git switch highscore-feature   # les fichiers sont revenus
git switch master                # les fichiers ont encore disparu

Étape 4 : Fusionner avec git merge

Ta feature highscore fonctionne. Il est temps de la remettre dans master. Ça s’appelle merger.

Assure-toi d’être sur master :

git switch master

Fusionne la branche :

git merge highscore-feature

Git affiche quelque chose comme Updating a1b2c3d..e4f5g6h et Fast-forward. Tes commits de highscore-feature font maintenant partie de master. Vérifie :

ls
git log --oneline

highscore.txt et highscore_manager.py sont maintenant sur master. Tous les commits de la branche feature sont repris dans l’historique.

Étape 5 : C’est quoi, un merge conflict ?

Imagine : tu as changé quelque chose sur master dans highscore.txt, par exemple “HIGHSCORE: 100” au lieu de “HIGHSCORE: 0”. Et en même temps, sur une autre branche, tu as aussi changé highscore.txt, en “HIGHSCORE: 500”.

Si tu essaies de merger maintenant, Git ne sait pas quelle version est la bonne. C’est un merge conflict. Git te demande à toi de décider.

Provoquons-le exprès.

Sur master :

echo "HIGHSCORE: 100" > highscore.txt
git add highscore.txt
git commit -m "Update highscore à 100 sur master"

Crée une nouvelle branche et change le même fichier :

git switch -c andere-highscore
echo "HIGHSCORE: 500" > highscore.txt
git add highscore.txt
git commit -m "Update highscore à 500"

Reviens sur master et essaie de merger :

git switch master
git merge andere-highscore

Git dit : CONFLICT (content): Merge conflict in highscore.txt. Ouvre highscore.txt dans ton éditeur. Tu vois :

<<<<<<< HEAD
HIGHSCORE: 100
=======
HIGHSCORE: 500
>>>>>>> andere-highscore

Ce sont les deux versions. HEAD, c’est ta version master. En dessous se trouve la version de andere-highscore. Tu choisis laquelle tu gardes, ou tu les combines.

Supprime les marqueurs et choisis une version :

HIGHSCORE: 500

Enregistre le fichier. Dis à Git que le conflit est résolu :

git add highscore.txt
git commit -m "Merge : highscore de andere-highscore choisi"

Conflit résolu. Git peut continuer.

Étape 6 : Ranger les branches

Ta feature est mergée. Tu n’as plus besoin de la branche :

git branch -d highscore-feature
git branch -d andere-highscore

-d veut dire « delete ». Git refuse de supprimer une branche qui n’est pas encore mergée : c’est une soupape de sécurité. Si tu veux vraiment jeter une branche sans la merger, utilise -D (majuscule). Mais fais attention avec ça.

Une branche ou pas, quand ?

Règle de base : si tu hésites, fais une branche. Une branche ne coûte rien. Perdre du code, si.

Astuces pour travailler vite avec les branches

1. Garde tes branches courtes. Une branche de 3 heures, c’est parfait. Une branche de 3 semaines devient un cauchemar de merge : plus tu attends pour merger, plus master change entre-temps, et plus le risque de conflicts augmente.
2. Une seule chose par branche. « Ajouter le highscore » est une bonne branche. « Ajouter le highscore, un menu et de nouveaux niveaux » est trop : découpe-le.
3. Merge souvent. Quand ta feature est finie, merge-la tout de suite dans master. Des merges petits et fréquents sont plus faciles qu’un seul gros merge monstre.
4. Donne des noms clairs à tes branches. highscore-feature, c’est bien. test123 ou branch2, c’est mauvais. Dans une semaine, tu ne sauras plus ce qu’il y avait dans test123.
5. Vérifie où tu es avant de commencer. git branch ou git status te dit sur quelle branche tu es. Fais-en une habitude, pour éviter d’écrire par accident du code sur master qui appartient en fait à une branche feature.

Showcase

Montre à un coach et à un buddy :

1. git branch avec au moins deux branches (dont master).
2. Sur chaque branche, un autre fichier ou d’autre code.
3. Le switch dans les deux sens : les fichiers apparaissent et disparaissent.
4. Un merge réussi d’une branche feature dans master.

À la prochaine !

« Jusqu’ici, tout ton code vit seulement sur ton laptop. La prochaine fois, on le met en ligne. Tu crées un compte GitHub, tu pushes ton dépôt sur internet, et ton jeu est visible partout dans le monde. Et : tu peux collaborer avec d’autres. GitHub : ton code dans le monde entier. »

À emporter chez toi

1. Facile : crée une branche pour une petite feature dans un projet existant. Committe ton travail et merge-la.
2. Moyen : crée exprès un merge conflict (deux branches qui modifient le même fichier) et résous-le.
3. Difficile : travaille avec trois branches en même temps sur le même projet. Merge-les une par une dans master. Vérifie après chaque merge que tout marche encore.
4. Très difficile : crée une branche, fais trois commits, reviens sur master, fais là aussi une modification dans le même fichier, et merge la branche. Résous le conflit soigneusement et vérifie avec git log --graph à quoi ressemble l’historique.

Session 13 : GitHub : ton code en ligne, pour tout le monde

Jusqu’ici, tout ton code vit sur ton laptop. Pratique pour toi, mais personne d’autre n’y a accès. Et si ton laptop plante, tu perds tout.

GitHub est un site web où tu mets tes dépôts Git en ligne. C’est une sauvegarde, un portfolio et une plateforme de collaboration en un seul. Aujourd’hui, tu mets ton code sur GitHub. À la fin de cette session, n’importe qui avec une connexion internet peut voir tes projets, et toi ceux des autres.

C’est quoi GitHub ?

GitHub, ce n’est pas la même chose que Git. Git est le système de gestion de versions qui tourne sur ton ordinateur. GitHub est un site web (github.com) qui héberge des dépôts Git : une sorte de Google Drive pour le code, mais avec Git en dessous.

Ce que GitHub ajoute à Git :

• Une sauvegarde dans le cloud. Ton code n’est pas seulement en local. Laptop cassé ? Ton code survit.
• La collaboration. Plusieurs personnes peuvent travailler sur le même repo. GitHub gère qui a le droit de faire quoi.
• Les pull requests. Tu demandes la permission de mettre tes modifications dans le projet de quelqu’un, avec discussion et review.
• Les issues. Signaler des bugs, proposer des features, suivre des tâches : tout se passe dans ton repo.
• Le portfolio. Ton profil GitHub, c’est ta carte de visite. Les employeurs le regardent.

GitHub n’est pas la seule option ; il y a des alternatives comme GitLab et Bitbucket. Mais GitHub est le plus grand, avec plus de 100 millions d’utilisateurs. Dans ces sessions, on utilise GitHub.

Étape 0 : Créer un compte GitHub

1. Ouvre github.com dans ton navigateur.
2. Clique sur Sign up.
3. Remplis ton adresse e-mail. Utilise la même adresse que celle que tu as configurée dans git config à la session 11 : ça évite des soucis.
4. Choisis un username. C’est ton identité sur GitHub. Choisis quelque chose que tu trouveras encore chouette dans 5 ans. Tu peux changer ton username plus tard, mais les anciens liens vers ton profil ne marcheront alors plus.
5. Vérifie ton compte via l’e-mail que GitHub envoie.
6. Choisis l’abonnement Free. Tout ce dont tu as besoin est gratuit : repos publics et privés illimités.

Astuce pour les coaches : vérifie que les ninjas ont accès à leur e-mail pendant la session. Certains laptops ne sont pas connectés au webmail. Prépare un plan B : si la vérification par e-mail ne marche pas, les ninjas peuvent vérifier leur compte GitHub plus tard à la maison. Le reste de la session marche aussi sans vérification.

Étape 1 : Ton premier dépôt sur GitHub

Tu as un projet local sur ton ordinateur (de la session 11). Tu vas le mettre en ligne.

Sur GitHub, clique en haut à droite sur l’icône + → New repository.

Remplis :

Clique sur Create repository.

GitHub affiche maintenant des instructions. Choisis le bloc sous "…or push an existing repository from the command line". Copie ces trois commandes : tu en auras besoin tout de suite.

Étape 2 : Relier ton dépôt local à GitHub

Dans ton terminal (dans ton dossier de projet) :

git remote add origin https://github.com/JOUW_USERNAME/mijn-eerste-git-project.git

Que se passe-t-il ici ? remote est un endroit externe où ton repo se trouve aussi. origin est le nom que tu donnes à cet endroit. « origin » est le nom par défaut de ta remote principale. Tu peux avoir plusieurs remotes (par exemple origin pour GitHub, backup pour GitLab), mais une seule suffit la plupart du temps.

Vérifie que ça a marché :

git remote -v

Tu vois :

origin  https://github.com/JOUW_USERNAME/mijn-eerste-git-project.git (fetch)
origin  https://github.com/JOUW_USERNAME/mijn-eerste-git-project.git (push)

fetch = c’est de là que tu récupères du code. push = c’est là que tu envoies ton code. La plupart du temps, c’est le même endroit.

Étape 3 : Mettre ton code en ligne avec git push

Voilà le moment : envoyer tes commits locaux vers GitHub.

git push -u origin master

push = envoie mes commits vers la remote. -u origin master = « retiens que master sur mon ordinateur correspond à master sur origin. » La prochaine fois, tu peux juste taper git push, parce que Git se souvient du lien.

GitHub demande de te connecter. Deux possibilités :

1. Via le navigateur : GitHub ouvre une fenêtre de navigateur, tu cliques sur « Authorize ». C’est fait.
2. Avec un Personal Access Token : crée-le via GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic). Donne un nom au token, coche repo, copie le token, et colle-le comme mot de passe dans le terminal.

Pour les ninjas : la méthode 1 (navigateur) est la plus simple. Si ça ne marche pas, aide-les avec un token.

Après un push réussi, rafraîchis ta page GitHub. Tes fichiers sont là ! Ton hallo.py, ton historique de commits : tout.

Étape 4 : Pusher des modifications

Fais une modification en local :

echo 'print("GitHub is cool!")' >> hallo.py
git add hallo.py
git commit -m "Add GitHub enthusiasm"

Pushe vers GitHub :

git push

Tu n’as plus besoin de -u origin master, parce que Git connaît le chemin. Rafraîchis GitHub : ton nouveau commit est là.

Étape 5 : Démarrer un nouveau projet via GitHub

C’est la route inverse : tu commences sur GitHub et tu le ramènes sur ton ordinateur.

Sur GitHub : New repository. Appelle-le python-spelletje. Cette fois, coche bien Add a README file ; GitHub crée alors un repo avec un fichier dedans. Clique sur Create repository.

Maintenant tu ramènes ce repo sur ton ordinateur. Ça s’appelle cloner :

cd ~   # va dans ton dossier home
git clone https://github.com/JOUW_USERNAME/python-spelletje.git

GitHub crée un dossier python-spelletje avec le README dedans. Et c’est tout de suite un dépôt Git complet : le dossier .git est déjà là. Tu ne dois pas faire de git init.

cd python-spelletje
git log --oneline   # tu vois le premier commit que GitHub a fait pour toi

Maintenant tu peux continuer à travailler ici en local et pusher tes commits vers GitHub, exactement comme aux étapes 3 à 4.

Étape 6 : Et si quelqu’un d’autre fait aussi des modifications ?

Imagine : tu as travaillé à python-spelletje à la maison et tu as pushé. Maintenant tu es au dojo avec un laptop et tu veux continuer. Tu n’as pas encore la dernière version.

git pull

git pull récupère les derniers commits de GitHub sur ton ordinateur. C’est deux actions en une : git fetch (récupérer) + git merge (fusionner avec ton code local).

Fais toujours git pull avant de commencer à travailler, sinon tu prends du retard et tu récoltes des merge conflicts.

Résumé du workflow :

Retiens : pull avant de commencer, push quand tu as fini.

Showcase

Montre à un coach et à un buddy :

1. Ton profil GitHub avec au moins un dépôt.
2. L’historique de commits de ton repo sur GitHub (clique sur “X commits” au-dessus de la liste des fichiers).
3. Un git push tout frais qui vient d’arriver sur GitHub.

À la prochaine !

« Maintenant ton code est en ligne. Mais qu’est-ce que tu mets dans un commit message ? Comment écrire un message qui sera encore clair dans trois mois ? Et comment travailler avec une équipe sans tout casser ? La prochaine fois : le côté professionnel de Git : les best practices que tous les développeurs utilisent. »

À emporter chez toi

1. Facile : pushe un projet local existant vers un nouveau dépôt GitHub.
2. Moyen : fais 3 commits en local, pushe-les, et vérifie sur GitHub qu’ils sont tous visibles.
3. Difficile : clone un repo de GitHub, fais une modification, committe et pushe.
4. Très difficile : simule un travail sur deux ordinateurs : clone un repo, fais un commit et pushe. Va dans un autre dossier, clone le même repo encore une fois (comme si c’était un autre ordinateur), fais un autre commit, et essaie de pusher. Que se passe-t-il ? Résous-le avec git pull.

Session 14 : Git Best Practices : écris des commits que tu comprendras encore plus tard

Tu sais taper des commandes Git. Ton code est sur GitHub. Mais il y a une différence entre « utiliser Git » et « bien utiliser Git ».

Cette session parle des habitudes que les développeurs expérimentés appliquent chaque jour. Pas de nouvelles commandes, mais des règles plus précises. À la fin, tu écriras des commit messages qui te serviront encore dans un an, et tu travailleras avec une stratégie de branching qui garde ton projet clair.

Ce que tu vas apprendre aujourd’hui

• Comment écrire un commit message qui dit quelque chose
• Trois règles simples pour le branching
• Ce qu’est git stash et quand l’utiliser
• La règle du pull avant le push

Partie 1 : Des commit messages qui disent quelque chose

Un mauvais commit message ressemble à ça :

git commit -m "fix"
git commit -m "update"
git commit -m "trucs modifiés"

Dans trois mois, tu regardes en arrière. C’était quoi « fix » ? Quels « trucs » ? Tu ne le sais plus. Tu dois fouiller dans le code pour retrouver ce qui s’est passé. C’est du temps perdu.

Le bon commit message : 3 parties

Un commit message professionnel a trois parties :

1. Un résumé court (72 caractères max)

Écris en anglais. Commence par un verbe au présent. Ça s’appelle l’« imperative mood » : comme si tu donnais un ordre à ta base de code. Pense : « Add », « Fix », « Remove », « Update », « Refactor ».

Add highscore tracking
Fix star spawning off-screen
Remove unused collision code

2. Une ligne vide

3. Une explication plus longue (optionnel, si c’est utile)

Add highscore tracking

Sauvegarde le meilleur score dans highscore.txt. Le score est
mis à jour après chaque game-over. Le fichier est créé s'il
n'existe pas encore.

Ça remplace l'ancienne méthode où le score restait seulement
en mémoire et se perdait à la fermeture du jeu.

L’explication détaillée raconte pourquoi tu as changé quelque chose, pas seulement quoi. Le code lui-même montre déjà le « quoi ». C’est le « pourquoi » dont tu auras besoin dans trois mois.

Les règles de commit message en un coup d’œil

Pourquoi l’anglais ? Parce que presque tous les projets open source utilisent l’anglais. Le code est international. Ton code Python aussi, tu l’écris en anglais (def calculate_score). Tes commit messages suivent la même langue.

Pourquoi le présent ? Un commit décrit ce que cette modification fait, pas ce que toi tu as fait. « Add feature » (ce commit ajoute une feature), pas « Added feature » (j’ai ajouté une feature un jour). Git lui-même utilise le présent : Merge branch 'feature', pas Merged.

Des commits multi-lignes dans le terminal

Tu peux écrire un commit message sur plusieurs lignes en ne fermant pas les guillemets :

git commit -m "Add highscore tracking

Sauvegarde le meilleur score dans highscore.txt. Le fichier est
créé automatiquement au premier game-over."

Attention : tu ne tapes le guillemet fermant qu’à la dernière ligne. Tout ce qu’il y a entre les deux fait partie de ton message.

Quand est-ce que tu committes ?

Committe souvent. Committe petit.

Pas : trois heures de travail, un seul commit énorme avec 47 fichiers modifiés. Oui : un commit toutes les 15 à 30 minutes, chaque fois qu’un petit morceau logique est fini.

Règle de base : si ton commit message contient « et », ton commit est trop gros. « Add highscore tracking et fix menu bug et update sprites » → ça doit être trois commits séparés.

Des petits commits facilitent :

• Comprendre ce qui a changé et quand
• Annuler une modification précise sans casser le reste
• Résoudre des merge conflicts (petits morceaux = moins de conflicts)

Partie 2 : Le branching : trois règles simples

Tu sais déjà comment créer des branches (session 12). Maintenant : quand et pourquoi.

Règle 1 : master marche toujours

La branche master, c’est ta vitrine. Quelqu’un qui clone ton repo doit pouvoir lancer ton code sans message d’erreur. master ne contient jamais du travail à moitié fini.

Pas ok sur master : du code avec # TODO: encore à finir, des fonctions en commentaire, des expériences que tu « répareras plus tard ».

Ok sur master : du code qui marche. Point.

Règle 2 : Une feature, une branche

Une branche fait exactement une chose. Pas plus.

• Bien : feature/player-health-bar
• Mauvais : feature/health-bar-and-menu-and-sound-effects

Si, en travaillant sur une feature, tu penses : « Oh, je peux aussi réparer ce bug de menu vite fait » : stop. Fais une nouvelle branche pour le bugfix. Merge-la d’abord. Ensuite, continue ta feature.

Règle 3 : Les branches ont une vie courte

Une branche qui existe depuis plus de quelques jours devient un problème. master change entre-temps, et ta branche prend du retard. Plus tu attends pour merger, plus le risque de merge conflicts augmente.

Merge ta branche dès que la feature est finie. Pour les petites choses (un bugfix de 10 minutes) : tu n’as peut-être même pas besoin d’une branche séparée.

Nommer les branches

Donne aux branches des noms que tu comprendras encore dans une semaine :

feature/highscore-tracking
bugfix/star-spawn-offscreen
experiment/particle-effects

Le préfixe (feature/, bugfix/, experiment/) dit tout de suite quel genre de travail se trouve dans cette branche. C’est une convention, pas une obligation technique, mais ça aide.

Partie 3 : Des commandes de workflow pratiques

git stash : mettre du travail de côté

Imagine : tu travailles sur une branche feature. Ton code est à moitié fini. Tu veux passer vite fait sur master pour un bugfix, mais tu ne veux pas committer ton travail à moitié fini. C’est pour ça que git stash existe :

git stash

Git garde toutes tes modifications de côté et remet ton working directory au dernier commit. Tu peux maintenant switcher, faire le bugfix, committer, et revenir :

git switch master
# ... faire le bugfix, committer ...
git switch feature-branch
git stash pop

git stash pop ramène tes modifications gardées de côté. Tout est de nouveau comme tu l’as laissé : à moitié fini, mais bien gardé.

git pull --rebase : un historique plus propre

Normalement, git pull fait un merge. Ça crée un commit de merge en plus. Parfois tu n’en veux pas ; tu veux une ligne droite de commits sans branches.

git pull --rebase

Ça récupère les derniers commits et met tes commits locaux par-dessus, comme si tu les avais faits après les commits du remote. Le résultat, c’est un historique linéaire : pas de merge-commits qui disent seulement « Merge branch ‘master’ ».

Attention : n’utilise --rebase que sur des branches que tu es seul à utiliser. Sur des branches partagées, un simple git pull (merge) est plus sûr.

La règle du pull avant le push

Avant de faire git push :

git pull

Toujours. Même si tu penses que personne d’autre n’a pushé. Ça prend une seconde et ça évite que GitHub refuse ton push avec « Updates were rejected because the remote contains work that you do not have locally. »

Cette règle compte surtout quand tu travailles à plusieurs. Si tu es le seul à travailler sur un repo, le risque est plus petit, mais l’habitude vaut de l’or.

Partie 4 : Le .gitignore qu’il te faut toujours

Chaque projet a des fichiers qui n’ont rien à faire dans Git. Ton .gitignore est ta première ligne de défense contre un mot de passe commité par accident.

.gitignore minimal pour un projet Python :

# Python
__pycache__/
*.pyc
*.pyo

# Environnement virtuel
venv/
.venv/

# Variables d'environnement (contiennent souvent des mots de passe/clés)
.env

# Ton éditeur
.vscode/
.idea/
*.swp
*.swo

# Fichiers du système
.DS_Store
Thumbs.db

Pourquoi ignorer __pycache__/ ? Ce sont des fichiers Python compilés que ton programme crée automatiquement. Ils sont différents selon la version de Python et selon l’ordinateur. Les mettre dans Git, ça ne fait que du bruit.

Pourquoi ignorer .env ? Les fichiers .env contiennent souvent des clés secrètes, des API keys, des mots de passe de base de données. Ceux-là ne doivent jamais, mais alors jamais, aller dans Git.

Showcase

Montre à un coach et à un buddy :

1. Tes 5 derniers commits, avec de bons commit messages.
2. Ton fichier .gitignore.
3. Un nom de branche qui suit la convention du préfixe feature/.

À la prochaine !

« Maintenant tu travailles avec Git comme un pro. Mais il reste un concept que chaque équipe utilise : la pull request. Ton code est prêt, mais avant qu’il arrive dans master, quelqu’un d’autre doit l’approuver. Comment ça marche ? La prochaine fois : les pull requests, le mur de review par lequel chaque modification doit passer. »

À emporter chez toi

1. Facile : réécris les commit messages de tes 5 derniers commits. Utilise les règles de cette session.
2. Moyen : crée une branche avec le préfixe feature/, travaille dedans, merge-la et supprime-la. Fais pareil pour une branche bugfix/.
3. Difficile : utilise git stash pour garder du travail à moitié fini, switch sur master, fais un fix rapide, push, et reviens sur ta feature avec git stash pop.
4. Très difficile : crée une situation où git pull échoue (clone ton repo dans deux dossiers, fais un commit différent dans les deux, push le premier, et essaie de pusher le second). Résous-le : git pull, répare le merge conflict, et seulement après, pushe.

Session 15 : Pull Requests : la porte d'entrée de ton projet

Tu as construit une feature sur une branche. De bons commit messages, du travail propre. Maintenant tu veux mettre ton code dans master.

Tu pourrais faire git merge et c’est fini. Mais en équipe, ça ne marche pas. Quelqu’un d’autre doit d’abord regarder ton code : vérifier les erreurs, le style, les choses que tu as oubliées. Voilà ce qu’est une pull request.

Une pull request (PR) est une demande : « Récupère mes modifications. » Tu l’ouvres sur GitHub. Tes coéquipiers regardent ton code, donnent du feedback. Toi, tu modifies des choses. C’est seulement quand tout le monde est content que le code part vers master.

Dans cette session, tu fais ta première pull request. Tu reviewes celle d’un buddy. Et tu découvres ce que ça fait vraiment, le travail d’équipe avec Git.

Ce que tu vas apprendre aujourd’hui

• Ce qu’est une pull request et pourquoi les équipes l’utilisent
• Ouvrir une PR sur GitHub
• Mettre à jour ta PR après du feedback
• Reviewer la PR de quelqu’un d’autre
• Merger une PR et nettoyer la branche

Étape 0 : Préparation : travailler en duo

Aujourd’hui, tu travailles avec un buddy. Décidez qui est l’auteur (celui qui construit la feature) et qui est le reviewer (celui qui regarde la PR). À la moitié, vous échangez.

L’auteur a besoin d’un repo GitHub auquel le reviewer a accès. La façon la plus simple :

1. L’auteur crée un repo sur GitHub (public).
2. L’auteur va dans Settings → Collaborators → Add people.
3. L’auteur invite le reviewer avec son username GitHub.
4. Le reviewer accepte l’invitation (par e-mail ou via les notifications GitHub).

Maintenant, vous pouvez tous les deux pusher vers le même repo.

Alternative (sans accès collaborator) : le reviewer forke le repo de l’auteur et ouvre une PR depuis le fork vers l’original. Mais aujourd’hui, on garde ça simple : accès collaborator direct.

Étape 1 : Créer et pusher une branche feature (auteur)

L’auteur clone le repo (si ce n’est pas encore fait) et crée une branche feature :

git clone https://github.com/AUTEUR_USERNAME/ons-samenwerk-project.git
cd ons-samenwerk-project
git switch -c feature/groet-functie

Crée un nouveau fichier :

echo 'def groet(naam):' > groet.py
echo '    return f"Hallo {naam}!"' >> groet.py

Committe et pushe :

git add groet.py
git commit -m "Add groet function

Retourne une salutation pour le nom donné."
git push -u origin feature/groet-functie

Étape 2 : Ouvrir une pull request (auteur)

1. Va sur ton repo sur GitHub.
2. GitHub affiche maintenant une barre jaune : « feature/groet-functie had recent pushes » : clique sur Compare & pull request. (Si tu ne vois pas la barre : clique sur l’onglet Pull requests, puis New pull request, choisis base: master ← compare: feature/groet-functie.)
3. Écris un titre clair : « Add groet function »
4. Écris une description. Une bonne description de PR a trois parties :

## Quoi

Une fonction `groet(naam)` qui retourne une salutation.

## Pourquoi

On a besoin d'une salutation réutilisable pour
l'interface utilisateur. Ça évite de devoir écrire
la même string à plusieurs endroits.

## Comment tester

```python
from groet import groet
print(groet("CoderDojo"))  # "Hallo CoderDojo!"

5. Clique sur **Create pull request**.

Ta PR est maintenant ouverte. Toute personne qui a accès au repo peut la voir. GitHub montre le diff : exactement quelles lignes tu as ajoutées (en vert) et supprimées (en rouge).

## Étape 3 : Reviewer une PR (reviewer)

Le reviewer ouvre la PR sur GitHub. Voici les étapes d'une review :

### 1. Lis la description

Tu comprends ce que fait cette PR ? Si non, demande des explications.

### 2. Regarde le diff

Clique sur l'onglet **Files changed**. GitHub montre chaque ligne modifiée. Regarde :

- **Est-ce que le code marche ?** Est-ce que tu le lancerais toi-même si tu le clonais ?
- **Est-ce que le style est cohérent ?** Les mêmes conventions de nommage que le reste du projet ?
- **Est-ce qu'il y a des erreurs ?** Des typos, des imports manquants, des erreurs de logique ?
- **Est-ce qu'il n'y a pas de secrets dedans ?** Des mots de passe, des API keys, des tokens ?
- **Est-ce que c'est compréhensible ?** Quelqu'un qui voit ce code pour la première fois peut-il suivre ce qui se passe ?

### 3. Donne du feedback

Clique sur une ligne pour ajouter un comment. Sois précis :

**Du bon feedback :**
> Dans `groet.py` ligne 2 : que se passe-t-il si `naam` est vide ? Peut-être ajouter une valeur par défaut ?

**Du mauvais feedback :**
> Ce n'est pas bon.

### 4. Envoie ta review

Clique sur **Review changes**. Tu as trois options :

- **Comment** : juste du feedback, pas de décision.
- **Approve** : le code est bon, il peut être mergé.
- **Request changes** : il faut changer quelque chose avant que la PR puisse être mergée.

Pour ta première review : choisis **Approve** si tout a l'air bon, ou **Request changes** si tu veux faire changer quelque chose.

## Étape 4 : Traiter le feedback (auteur)

Le reviewer a laissé un comment. L'auteur modifie le code :

```bash
# Vérifie que tu es bien sur ta branche feature
git switch feature/groet-functie

Modifie groet.py sur base du feedback. Par exemple :

def groet(naam="wereld"):
    return f"Hallo {naam}!"

Committe et pushe :

git add groet.py
git commit -m "Add default parameter to groet function"
git push

Le nouveau commit apparaît automatiquement dans la PR. Le reviewer voit la mise à jour et peut regarder à nouveau.

Étape 5 : Merger et nettoyer

Si le reviewer a mis Approved, il est temps de merger.

Sur GitHub, dans la PR, tu cliques sur Merge pull request. Choisis Create a merge commit (l’option par défaut). Clique sur Confirm merge.

La branche feature est maintenant fusionnée avec master. Sur GitHub, tu peux supprimer la branche avec le bouton Delete branch qui apparaît après le merge.

En local, tu dois aussi nettoyer :

git switch master
git pull                      # récupère le merge qui vient d'avoir lieu sur GitHub
git branch -d feature/groet-functie   # supprime la branche locale

Ton master est maintenant up-to-date. Ta branche feature a disparu, en local et sur GitHub. Prêt pour le prochain morceau de travail.

Le workflow PR complet en un coup d’œil

1. git switch -c feature/iets        ← Crée une branche feature
2. Travaille, committe, travaille, committe
3. git push -u origin feature/iets   ← Push vers GitHub
4. Ouvre une PR sur GitHub           ← Demande une review
5. Le reviewer regarde, donne du feedback
6. Modifie le code, committe, pushe  ← Traite le feedback
7. Le reviewer a approuvé
8. Merge la PR sur GitHub            ← Le code part vers master
9. git switch master && git pull       ← Récupère master en local
10. git branch -d feature/iets       ← Nettoie la branche

Reviewer la PR de quelqu’un d’autre : comment bien faire ?

Une review, ce n’est pas : « Ça a l’air bon. » Une bonne review est précise, constructive et respectueuse.

Les questions que tu te poses pendant une review :

• Est-ce que je comprends ce que fait ce code ? (Si non : demande de meilleurs comments ou une description plus claire.)
• Est-ce que le code fait ce que promet la description de la PR ?
• Est-ce que ça peut être plus simple ?
• Est-ce qu’il manque quelque chose ? (Gestion des erreurs, edge cases, documentation)
• Est-ce qu’il y a des secrets, des mots de passe ou des données personnelles dedans ?
• Est-ce que le code suit le style du reste du projet ?

Comment donner du feedback :

Commence par ce qui est bien. Sois ensuite précis sur ce qui peut être mieux. Termine par une conclusion claire.

Exemple :

La fonction marche exactement comme décrit. Deux suggestions :

1. À la ligne 2 : une valeur par défaut pour naam serait pratique.
2. Pense à ajouter une docstring qui explique ce que la fonction retourne.

Pour le reste, ça a l’air bon. Si tu changes ces deux choses, je l’approuve avec plaisir.

Showcase

Échange ton rôle avec ton buddy et refais tout le workflow une fois : maintenant, c’est toi le reviewer.

Montre à un coach :

1. Une pull request ouverte sur GitHub avec une description.
2. Au moins un comment de review sur une PR de ton buddy.
3. Une PR mergée avec succès : le code de la feature est maintenant sur master.

À la prochaine !

C’était la dernière session Git. Ce que tu sais faire maintenant :

• Gérer les versions de ton code avec Git (init, add, commit, log, diff)
• Expérimenter sur des branches sans casser master (branch, switch, merge)
• Partager ton code en ligne via GitHub (push, pull, clone)
• Écrire des commit messages professionnels
• Travailler à plusieurs via des pull requests : en ouvrir et en reviewer

Ce n’est pas « en plus ». C’est comme ça que les développeurs travaillent chaque jour. Que tu fasses des jeux, des sites web ou de l’IA : Git et GitHub sont les outils qui gardent ton projet sous contrôle. Utilise-les.

À emporter chez toi

1. Facile : ouvre une pull request pour une modification dans un de tes propres projets.
2. Moyen : demande à un ami ou à un membre de ta famille de créer un compte GitHub. Invite-le comme collaborator et laisse-le reviewer une PR.
3. Difficile : contribue à un vrai projet open source. Cherche sur GitHub des issues avec le label good first issue. Forke le repo, fais un fix et ouvre une PR.
4. Très difficile : construis un petit projet avec deux autres personnes. Utilise des branches, des pull requests et des reviews. Travaille comme si tu étais dans une équipe professionnelle.

Session 16 : Markdown : écris des notes qui ressemblent au web

Tu connais peut-être HTML par internet : <h1>, <p>, <a>. Mais pour des notes et de la documentation, HTML demande beaucoup trop de frappe. C’est pour ça que Markdown existe.

Markdown est un mini-langage que tu écris en texte normal. Ça reste lisible sans devoir d’abord le convertir. Et d’une seule pression sur un bouton, ça devient du HTML propre : des titres, des listes, des liens, des tableaux.

Dans cette session, tu apprends toute la base de Markdown. À la fin, tu écriras des notes qui ont l’air professionnelles, sur GitHub, dans Obsidian, ou dans n’importe quel autre programme qui comprend Markdown.

Ce que tu vas apprendre aujourd’hui

• Faire des titres et des paragraphes
• Mettre en forme du texte : gras, italique, barré
• Les listes et les énumérations
• Des liens vers d’autres pages et des sites web
• Insérer des images
• Faire des tableaux
• Des lignes horizontales et des blocs de code

Pourquoi Markdown ?

Markdown est partout :

• GitHub : chaque repo a un README.md en Markdown. Les issues, les pull requests, les wikis : tout est en Markdown.
• Obsidian, Joplin, Logseq : des applis de notes qui enregistrent tes documents comme fichiers .md.
• Discord, Slack, Reddit : ils supportent Markdown pour mettre en forme vite fait tes messages.
• Hugo (ce site !) : toutes les pages de session que tu vois ici sont écrites en Markdown.
• Jupyter Notebooks : les cellules de texte sont en Markdown.

Le grand avantage : tu écris du texte normal. Pas de tags compliqués. Et le résultat reste toujours lisible, même en texte brut.

Étape 0 : Créer un fichier Markdown

Les fichiers Markdown se terminent par .md. Crée-en un :

mkdir mijn-notities
cd mijn-notities
echo "# Ma première note" > test.md

Tu peux ouvrir des fichiers .md dans n’importe quel éditeur de texte : le Bloc-notes, VS Code, Thonny, Obsidian. VS Code a une preview intégrée : clique en haut à droite sur l’icône avec la loupe et le livre.

Étape 1 : Titres et paragraphes

Tu fais des titres avec #. Plus il y a de #, plus le titre est petit :

# Ceci est un titre (h1)

## Ceci est un sous-titre (h2)

### Ceci est un titre plus petit (h3)

#### Encore plus petit (h4)

Tu fais un paragraphe en tapant simplement du texte. Une ligne vide entre les deux commence un nouveau paragraphe :

Ceci est le premier paragraphe. Il continue comme ça.

Ceci est le deuxième paragraphe. Parce qu'il y a une ligne vide entre les deux.

Astuce : tu n’utilises # qu’une seule fois par document : pour le titre. Le reste commence à ##.

Étape 2 : Mettre en forme du texte

**Ceci est en gras**

*Ceci est en italique*

~~Ceci est barré~~

Tu peux aussi **mettre du *gras* et de l'italique ensemble** dans la même phrase.

Le résultat :

• **gras** devient gras
• *italique* devient italique
• ~~barré~~ devient barré

Attention : pas d’espaces entre les astérisques et le texte. ** gras ** ne marche pas. **gras** oui.

Certains éditeurs acceptent aussi les underscores : __gras__ et _italique_. Mais les astérisques sont le standard : utilise-les.

Étape 3 : Lignes horizontales

Tu fais une ligne horizontale avec trois tirets (ou plus) :

---

Ou avec des astérisques :

***

Le résultat est une ligne sur toute la largeur. Utilise-le avec parcimonie : une ou deux par document, c’est assez. Trop de lignes rendent tes notes brouillonnes.

Étape 4 : Listes

Liste non numérotée

Utilise -, * ou + :

- Python
- Git
- Markdown
- GitHub

Tu peux imbriquer des listes en indentant (2 ou 4 espaces) :

- Langages de programmation
  - Python
  - JavaScript
- Gestion de versions
  - Git
  - GitHub

Liste numérotée

1. Ouvre Thonny
2. Écris ton code
3. Clique sur Run

Peu importe les numéros que tu tapes : Markdown numérote automatiquement. Ceci :

1. Étape un
1. Étape deux
1. Étape trois

…donne exactement le même résultat que 1, 2, 3. Pratique si tu veux ajouter une étape plus tard sans tout renuméroter.

Checklist (style GitHub)

- [x] Installer Git
- [x] Faire ton premier commit
- [ ] Apprendre les branches
- [ ] Ouvrir une pull request

[x] est coché, [ ] est ouvert. Ça marche dans les issues GitHub, les pull requests, et beaucoup d’applis de notes.

Étape 5 : Liens

Liens externes (vers des sites web)

[clique ici pour le site CoderDojo](https://python.coderdojohasselt.be)

Le mot entre [ ] est le texte cliquable. L’URL entre ( ) est la destination.

Liens internes (vers d’autres pages de ton projet)

[Voir la session 11](11-git-intro/)

Ça fait un lien vers le fichier 11-git-intro/_index.md dans le même dossier.

Lien rapide (montre l’URL directement)

<https://github.com>

Ça montre l’URL comme lien cliquable, sans texte séparé.

Étape 6 : Images

Une image, c’est presque la même chose qu’un lien, mais avec un ! devant :

![Une étoile dans Pygame Zero](/sessions/01-catch-the-stars/coordinaten.svg)

Le texte entre [ ] est le texte alt : il apparaît si l’image ne charge pas, ou il est lu par les screen readers.

Images et Git : Les petites images (SVG, petits PNG), tu peux les mettre dans Git. Les grosses images (>1 MB) et les vidéos, mieux vaut éviter, parce qu’elles ralentissent ton repo.

Étape 7 : Tableaux

| Commande | Ce qu'elle fait |
|----------|-------------|
| `git init` | Créer un nouveau dépôt |
| `git add` | Préparer des fichiers pour le commit |
| `git commit` | Enregistrer les modifications |
| `git push` | Envoyer les commits vers GitHub |

Les caractères | forment les colonnes. La ligne --- sépare l’en-tête des données. Le : dans la ligne de séparation détermine l’alignement :

| Aligné à gauche | Centré | Aligné à droite |
|:-----------------|:-----------:|------------------:|
| gauche           | milieu      | droite            |

Étape 8 : Code et blocs de code

Code inline

Utilise des backticks pour de courts bouts de code dans une phrase :

Utilise `git status` pour voir ce qui a changé.

Blocs de code

Pour plusieurs lignes de code, tu utilises trois backticks :

```python
def groet(naam):
    return f"Hallo {naam}!"
```

La langue (python) derrière les premiers backticks donne du syntax highlighting. Ça marche pour des dizaines de langues : bash, html, css, javascript, json, yaml, markdown.

Bloc de code sans langue

```
Ceci est juste du texte
sans syntax highlighting
```

Étape 9 : Blockquotes

Utilise > pour des citations ou des remarques importantes :

> Git n'est pas un back-up. Git est une machine à remonter le temps.
> Quelqu'un sur internet

Plusieurs lignes > à la suite forment un seul bloc. Une ligne > vide commence un nouveau paragraphe à l’intérieur de la citation.

Étape 10 : Tout ensemble : un vrai README

Un bon README.md combine tout ce que tu connais maintenant. Voici un exemple :

# Mon projet

Une courte description de ce que fait ce projet.

## Installation

```bash
git clone https://github.com/jouw-naam/mijn-project.git
cd mijn-project
```

## Utilisation

1. Ouvre `main.py` dans Thonny.
2. Clique sur **Run**.
3. Choisis un niveau et démarre.

## Ce que tu apprends

- [x] Bases de Pygame Zero
- [x] Collision detection
- [ ] Système de highscore
- [ ] Effets sonores

## Liens

- [CoderDojo Hasselt](https://coderdojohasselt.be)
- [Code source sur GitHub](https://github.com/jouw-naam/mijn-project)

Cheatsheet

Showcase

Montre à un coach et à un buddy :

1. Un document Markdown avec au moins un titre, une liste, un lien et du texte en gras.
2. Un tableau avec au moins deux colonnes et trois lignes.
3. Une checklist avec des items cochés et des items ouverts.

À la prochaine !

Markdown est simple, mais il est partout. Tes README sur GitHub, tes notes dans Obsidian, ta documentation : tout devient plus lisible avec Markdown. Utilise-le. N’en fais pas trop avec la mise en forme. De bonnes notes sont claires, pas chargées.

À emporter chez toi

1. Facile : écris un README.md pour ton projet Python préféré. Utilise des titres, une liste et un bloc de code.
2. Moyen : fais une note dans Obsidian (ou un autre éditeur Markdown) sur ce que tu as appris ce mois-ci. Utilise toute la mise en forme du cheatsheet au moins une fois.
3. Difficile : construis une page « cheatsheet » en Markdown pour un sujet de ton choix (commandes Git, syntaxe Python, formules de maths). Utilise des tableaux et des listes imbriquées.
4. Très difficile : fais un document Markdown avec une liste imbriquée qui va au moins sur trois niveaux de profondeur, un tableau avec de l’alignement, et un bloc de code avec du syntax highlighting.