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.