Mini-défi : un historique propre

Construire un historique atomique avec .gitignore.

◷ 30 minutesTravail sur votre machine

Objectifs

Produire un historique de projet professionnel : commits atomiques, messages lisibles, fichiers ignorés correctement.

🔗 Pour vous rafraîchir la mémoire : codes de retour ($?, &&, ||) · manipulation de fichiers (cp, mv, rm) · redirections et pipes

Énoncé

Vous démarrez un petit projet « gestionnaire de recettes ». Construisez-le en versionnant à chaque étape :

Créez le dépôt avec README.md (titre + description en deux lignes) — commit 1.
Ajoutez recettes/pates.txt et recettes/gateau.txt — commit 2.
Ajoutez un dossier notes/ contenant idees.txt et un fichier vide journal.log — mais vous décidez que les fichiers .log ne doivent jamais être versionnés. Faites en sorte que Git ignore journal.log tout en gardant idees.txt — commit 3.
Modifiez une recette ET ajoutez une nouvelle recette dans le même commit ? Non : séparez-les en deux commits distincts (commits 4 et 5).
Vérifiez le résultat final.

Contraintes

Messages d'une ligne, au présent, décrivant l'intention (« Ajoute la recette du gâteau »).
Aucun commit ne doit mélanger deux intentions différentes.
À la fin, git status doit être propre (rien de non suivi ni modifié).

Indices

Sur l'étape 3 : créez un fichier .gitignore à la racine contenant une ligne *.log. Le .gitignore lui-même, lui, se versionne : c'est une règle du projet.

Sur l'étape 4 : git add accepte des fichiers précis. Modifiez les deux fichiers, puis stagez-en un seul pour le premier commit, l'autre pour le second.

Pour vérifier : git log --oneline, git status, et git show --stat HEAD pour voir le contenu du dernier commit.

Ce qui ne doit jamais être versionné

Le .gitignore n'est pas une formalité : certaines catégories de fichiers doivent systématiquement en être exclues, chacune pour une raison précise.

Les secrets (.env, clés API, certificats) : versionnés, ils finissent poussés vers le remote et donc lisibles par toute personne ayant accès au dépôt — souvent pour toujours, car l'historique conserve chaque commit. Ils vivent hors Git et se documentent via un fichier d'exemple (.env.example) sans valeurs.
Les dépendances (node_modules/) : des milliers de fichiers reconstruisibles à volonté depuis package.json + lockfile. Les versionner alourdirait chaque commit sans aucun bénéfice — et masquerait les vraies modifications.
Les artefacts de build (dist/, build/, *.min.js) : produits régénérables par compilation. Les versionner doublerait chaque changement dans l'historique et créerait des divergences entre sources et binaires.
Les logs et données locales (*.log, bases SQLite de dev) : volumineux, volatils, parfois sensibles.
Les fichiers d'environnement personnel (.DS_Store, .idea/, .vscode/ selon l'équipe) : propres à votre machine, inutiles aux autres.

Le test mental : « ce fichier peut-il être recréé depuis le dépôt ? » Si oui, il n'a rien à y faire. Sinon (code, config partagée, documentation), il doit y être.

Correction disponibleCherchez d’abord par vous-même.Voir la correction

Correction

Solution complète

mkdir recettes-app && cd recettes-app
git init
echo "# Gestionnaire de recettes" > README.md
echo "Petit projet pour apprendre Git." >> README.md
git add README.md
git commit -m "Initialise le projet"

mkdir recettes
echo "Pâtes carbonara : ..." > recettes/pates.txt
echo "Gâteau au yaourt : ..." > recettes/gateau.txt
git add recettes/
git commit -m "Ajoute les premières recettes"

echo "Idée : filtre par ingrédient" > notes-idees.txt
mkdir notes && mv notes-idees.txt notes/idees.txt
touch journal.log
echo "*.log" > .gitignore
git add .gitignore notes/
git commit -m "Ignore les journaux et ajoute les idées"

echo "... (ajout de la crème)" >> recettes/pates.txt
git add recettes/pates.txt
git commit -m "Complète la recette des carbonara"

echo "Tarte tatin : ..." > recettes/tatin.txt
git add recettes/tatin.txt
git commit -m "Ajoute la tarte tatin"

Vérifications attendues

git status → nothing to commit, working tree clean.
git log --oneline → 5 commits, chacun avec une intention unique.
git ls-files → aucun .log ; le .gitignore est présent.
git check-ignore journal.log confirme que la règle s'applique.

Pourquoi c'est important

Un historique atomique permet de relire le projet comme une histoire (« quand ai-je ajouté X ? »), d'annuler précisément (git revert <hash> annule UNE intention), et de collaborer sans noyer les autres. C'est ce même historique qui alimentera vos futurs déploiements (chapitre CI/CD) : chaque commit y sera testé et déployé.