Les Lignes du Temps

Introduction

« Apprenti, tu as prouvé ta valeur. Tu sais créer des archives et y consigner des entrées. Mais un véritable Archiviste ne se contente pas d'écrire - il sait aussi lire le passé. Aujourd'hui, je te confie une archive ancienne. Des générations d'archivistes y ont consigné l'histoire du royaume. Ta mission : explorer ces lignes du temps et en percer les secrets. »

Récupérer l'archive

Le Maître Archiviste te tend un vieux coffre scellé - une archive complète du royaume. Pour l'ouvrir :

git clone archive.bundle les-lignes-du-temps
cd les-lignes-du-temps

Tu te retrouves avec une copie locale de toute l'archive. Voyons ce qu'elle contient.

Explorer l'historique

Git conserve chaque modification sous forme de commits - comme les pages d'un livre d'histoire. Voici les commandes pour naviguer dans le temps.

Voir la liste complète des commits

git log

Affiche tous les commits, du plus récent au plus ancien, avec l'auteur, la date et le message. L'affichage se fait page par page - utilise les flèches pour naviguer et appuie sur q pour quitter.

Version compacte (une ligne par commit)

git log --oneline

Chaque commit tient sur une ligne : son hash (identifiant unique, abrégé) et son message. C'est la vue la plus pratique pour avoir une vision d'ensemble.

Avec un graphe (aperçu des branches)

git log --oneline --graph

Ajoute un petit dessin ASCII qui montre la structure de l'historique. On verra les branches en détail dans une prochaine quête, mais c'est joli à regarder.

Détail d'un commit précis

git show <hash>

Remplace <hash> par le hash (court ou long) d'un commit. Tu verras exactement quels fichiers ont été modifiés et quelles lignes ont changé.

Comparer deux moments dans le temps

git diff <hash1> <hash2>

Montre les différences entre deux commits. Les lignes ajoutées apparaissent en vert (précédées de +), les lignes supprimées en rouge (précédées de -).

Filtrer par auteur

git log --author="Aldric"

N'affiche que les commits faits par un auteur donné. La recherche est partielle : "Aldric" trouvera "Aldric le Scribe".

Chercher dans les messages

git log --grep="dragon"

N'affiche que les commits dont le message contient le mot recherché.

Mission d'exploration

Il est temps de mettre tes nouvelles compétences en pratique. En utilisant les commandes ci-dessus, réponds à ces questions :

1. Combien de commits contient l'archive ?
   (indice : git log --oneline et compte, ou utilise git rev-list --count HEAD)
2. Quel auteur a fait le plus de commits ?
3. Trouve le commit qui mentionne "dragon" dans son message. Quel est son hash ?
4. Quel fichier a été modifié dans le 3ème commit ?
   (indice : git log --oneline pour trouver le hash, puis git show <hash>)
5. Trouve les commits avec de mauvais messages - "fix", "trucs", "modif", "wip", "oups". Utilise git show sur chacun : qu'auraient-ils dû dire à la place ?

Le .gitignore - Les fichiers à ne jamais archiver

En explorant l'archive, tu as peut-être remarqué des fichiers suspects : debug.log, .DS_Store, Thumbs.db, un dossier __pycache__/... Ces fichiers n'auraient jamais dû être archivés. Ce sont des fichiers parasites - générés automatiquement par le système ou les outils, ils polluent l'archive sans apporter aucune valeur.

Et il y a pire : secret-du-royaume.txt contient des informations confidentielles. Un secret committé par erreur reste dans l'historique pour toujours (ou presque). C'est une leçon importante.

Le fichier .gitignore

Pour éviter ces erreurs, Git propose un mécanisme simple : un fichier nommé .gitignore à la racine du projet. Chaque ligne contient un pattern de fichiers à ignorer.

Syntaxe

# Ceci est un commentaire

# Ignorer un fichier précis
debug.log
secret-du-royaume.txt

# Ignorer tous les fichiers avec une extension donnée
*.log
*.tmp

# Ignorer un dossier entier (et tout son contenu)
__pycache__/
node_modules/

# Ignorer des fichiers système
.DS_Store
Thumbs.db

# Ignorer les fichiers d'environnement (secrets, mots de passe)
.env
.env.local

Patterns courants à connaître

Attention : .gitignore ne supprime pas ce qui est déjà tracké

git rm --cached debug.log

Les bonnes pratiques de messages de commit

En explorant l'archive, tu as vu deux types de messages :

Les règles d'or

1. Commence par un verbe à l'infinitif ou à l'impératif : "Ajouter", "Corriger", "Mettre à jour", "Supprimer", "Refactoriser"...
2. Sois court : le titre fait 50 caractères maximum.
3. Sois descriptif : explique le pourquoi, pas juste le quoi. "Corriger le calcul de taxe qui arrondissait à l'entier" est mieux que "fix bug".
4. Écris pour les autres (et pour ton futur toi) : dans 6 mois, tu seras content de comprendre ce que tu as fait.

Pour aller plus loin : Conventional Commits

Il existe une convention populaire appelée Conventional Commits qui préfixe les messages :

feat: Ajouter le système de recherche
fix: Corriger le calcul du score
docs: Mettre à jour le guide d'installation
refactor: Simplifier la logique de validation

Ce n'est pas obligatoire, mais c'est de plus en plus courant dans les projets professionnels.

Exercice final - Nettoyer l'archive

Étape 1 - Créer un .gitignore

Dans le dossier les-lignes-du-temps/, crée un fichier .gitignore avec au minimum ces patterns :

# Fichiers de log
*.log

# Fichiers système
.DS_Store
Thumbs.db

# Cache Python
__pycache__/

# Secrets (ne jamais archiver !)
secret-du-royaume.txt

Étape 2 - Retirer les fichiers parasites du suivi

Ces fichiers sont déjà trackés par Git. Le .gitignore seul ne suffit pas - il faut les retirer du suivi :

git rm --cached debug.log
git rm --cached .DS_Store
git rm --cached Thumbs.db
git rm --cached -r __pycache__/
git rm --cached secret-du-royaume.txt

Étape 3 - Commiter le nettoyage

git add .gitignore
git commit -m "Ajouter le .gitignore et retirer les fichiers parasites du suivi"

Remarque le message : il est clair, descriptif, et commence par un verbe.

Étape 4 - Vérifier

Lance le script de vérification pour valider ta quête :

Bash (Linux / macOS / Git Bash sur Windows) :

bash verifier.sh

PowerShell (Windows) :

.\verifier.ps1

Le script vérifie :

1. Tu es dans un dépôt Git
2. Un fichier .gitignore existe
3. Le .gitignore contient un pattern pour les fichiers .log
4. debug.log n'est plus suivi par Git
5. Ton dernier commit a un message descriptif (au moins 10 caractères)