feat(terminal): real git branches, merges and conflicts, matching Git 2.56

CHANGELOG.md

@@ -5,7 +5,24 @@
 
 ---
 
-## 🌿 30 septembre 2026 — Git se comporte comme le vrai Git
+## 🌳 29 septembre 2026 — Les branches Git existent pour de vrai
+
+*Modules Git et GitHub · valeurs attendues relevées sur Git 2.56 · identifiants de commit identiques à ceux du vrai Git*
+
+Jusqu'ici, une branche du simulateur n'était qu'un nom. Changer de branche ne changeait aucun fichier, `git merge` inventait un commit de fusion sans rien fusionner, et la leçon sur les conflits n'en montrait jamais un. Chaque branche a maintenant ses commits et ses fichiers, et les fusions se calculent comme dans Git.
+
+- **Changer de branche change les fichiers.** `git switch` et `git checkout` remettent le dossier dans l'état de la branche. Une modification en cours suit l'élève, et Git la signale (`M` devant `README.md`). Si elle risque d'être écrasée, le changement est refusé avec le message exact de Git.
+- **Des fusions calculées, pas mimées.** `git merge` fait simplement avancer la branche quand c'est possible (`Fast-forward`). Si les deux branches ont avancé chacune de leur côté, il crée un commit de fusion. Deux modifications qui ne se touchent pas sont gardées toutes les deux.
+- **De vrais conflits.** Quand deux branches changent la même ligne, Git s'arrête et écrit les deux versions dans le fichier, entre `<<<<<<<`, `=======` et `>>>>>>>`. `git status` montre le fichier en conflit, `git add` puis `git commit` concluent la fusion, et `git merge --abort` l'annule. La leçon « Conflits de merge » en provoque un vrai : `main` et la branche ont chacune changé le titre de `index.html`.
+- **Un historique lisible comme dans Git.** `git log` retrouve son vrai format : identifiant, auteur, date, et à côté du commit les noms de branche et de tag (`HEAD -> main, tag: v1.0`). Il accepte aussi `--oneline`, `-n`, `--all`, `--author`, `--grep`, `--stat`, `-p`, les plages comme `main..feature` et `--graph` quand l'historique est linéaire. `git show` affiche un commit avec ses changements, ou un fichier tel qu'il était dans un commit (`git show HEAD~1:README.md`).
+- **Comparer des branches.** `git diff main feature` montre ce qui sépare deux branches, `git diff main...feature` ce que la branche a ajouté depuis qu'elle est partie de `main`, et `--stat` en donne le résumé. `git tag -n` affiche le message de chaque tag, et `--contains` ou `--merged` filtrent la liste.
+- **Les erreurs aussi sont celles de Git.** Un nom de branche ou de tag invalide, une option inconnue, deux noms là où Git n'en attend qu'un : le message est celui de Git, mot pour mot. Les textes d'aide (`usage: git branch …`) sont copiés automatiquement depuis Git 2.56, pas retapés à la main.
+- **Les mêmes identifiants que Git.** Mêmes fichiers, même auteur, même date et même message : le commit reçoit le même identifiant que dans un vrai dépôt. Un test le vérifie sur des commits, une fusion et un tag.
+- **`git tag`, `git reset`, `git cherry-pick` et `git rebase` travaillent sur ce vrai historique.** Certaines situations ne sont pas encore simulées : le rebase interactif, un conflit pendant un cherry-pick, la « tête détachée », le dessin de `--graph` quand les branches se séparent. Le terminal le dit clairement au lieu d'inventer une réponse.
+
+---
+
+## 🌿 29 septembre 2026 — Git se comporte comme le vrai Git
 
 *Modules Git et GitHub · valeurs attendues relevées sur Git 2.56 · écarts de la théorie : 158 → 148*
 

STORY.md

@@ -21,7 +21,19 @@ Ce projet a été construit avec l'aide de Claude — l'IA d'Anthropic, des mod
 
 ---
 
-## Un Git qui ne ment plus (30 septembre 2026)
+## Des branches qui existent vraiment (29 septembre 2026)
+
+Thierry avait posé la question simplement : « Pour Git, c'est très basique, je présume que c'est l'équivalent d'un premier niveau ? » C'était vrai, et pour une raison précise. On ne peut pas enseigner les branches avec un simulateur où une branche n'est qu'un nom. Il l'a dit mieux que moi : on n'apprend rien correctement sans une théorie et une pratique qui fonctionnent. Avant d'écrire la moindre leçon avancée, il fallait donc que le moteur fusionne pour de bon.
+
+Chaque commit connaît maintenant ses parents, et chaque branche pointe sur l'un d'eux. J'ai pris une décision de plus : calculer l'identifiant d'un commit exactement comme Git le calcule, à partir des fichiers, de l'auteur, de la date et du message. Pour le vérifier, j'ai créé les mêmes commits dans un vrai Git, à des dates fixées, et comparé : le simulateur donne les mêmes identifiants, fusion et tag compris.
+
+Le vrai Git m'a encore appris quelque chose. Pour relever ses messages, je redirigeais sa sortie vers un fichier, et j'y lisais une fusion refusée avant la ligne `Updating…`. Dans un vrai terminal, c'est l'inverse : Git écrit ses messages normaux et ses erreurs par deux canaux différents, et une redirection change leur ordre d'arrivée. J'ai donc relancé Git dans un pseudo-terminal, qui se comporte comme un vrai écran. C'est l'ordre de l'écran que l'élève voit, et c'est lui que les tests vérifient maintenant.
+
+Tout n'est pas encore là, et le terminal ne fait pas semblant. Le rebase interactif ouvre un éditeur, le dessin des branches par `git log --graph` demande un algorithme à part entière, et un conflit pendant un cherry-pick crée un état intermédiaire que nous ne simulons pas encore. Dans ces cas-là, le terminal le dit. Prochaine étape : des leçons en plusieurs étapes, vérifiées sur l'état réel du terminal, où l'élève provoque et résout lui-même ses conflits.
+
+---
+
+## Un Git qui ne ment plus (29 septembre 2026)
 
 Dans le simulateur, `git add fichier-qui-n-existe-pas.txt` répondait poliment `staged:`. Le vrai Git refuse : `fatal: pathspec … did not match any files`. Ce n'était pas un détail. Nos propres tests ajoutaient des fichiers imaginaires, et la leçon sur `git add .` avertissait que la commande embarque le fichier `.env`, alors que notre Git cachait justement les fichiers commençant par un point. La leçon et le moteur se contredisaient.