Objectifs

Produire un historique de projet professionnel : commits atomiques, messages lisibles, fichiers ignorés correctement — et savoir expliquer pourquoi chaque choix compte.

🔗 Pour vous rafraîchir la mémoire : vos premiers commits · manipulation de fichiers

Énoncé

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

1. Créez le dépôt avec un README.md (titre + description en deux lignes) — commit 1.
2. Ajoutez recettes/pates.txt et recettes/gateau.txt — commit 2.
3. 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.
4. Modifiez une recette ET ajoutez une nouvelle recette... puis séparez ces deux intentions en deux commits distincts (commits 4 et 5).
5. Vérifiez le résultat final selon les critères ci-dessous.

Critères d'acceptation

• Messages d'une ligne, au présent, décrivant l'intention (« Ajoute la recette du gâteau »).
• Aucun commit ne mélange deux intentions différentes.
• À la fin : git status propre (working tree clean).
• git ls-files ne montre aucun .log, mais montre bien le .gitignore.
• Cinq commits au total dans git log --oneline.

Contraintes

• Une intention par commit : c'est LA compétence visée par ce défi.
• Aucune utilisation de git add . aveugle : stagez des fichiers précis.

Indices

Sur l'étape 3 : créez un fichier .gitignore à la racine contenant une ligne :

*.log

La règle s'applique rétroactivement aux fichiers non encore suivis : Git refusera de proposer journal.log. Le .gitignore lui-même se versionne — c'est une règle du projet, pas une préférence personnelle : il doit suivre le code partout où celui-ci va.

Sur l'étape 4 : c'est le cœur du défi. Modifiez les deux recettes, puis regardez git status : les DEUX apparaissent modifiées. La staging area existe précisément pour cela — stagez un seul fichier (git add recettes/pates.txt), committez ; recommencez avec l'autre. Deux intentions, deux commits, zéro mélange.

Pour vérifier :

git log --oneline           # l'histoire racontée en cinq lignes
git status                  # propre ?
git show --stat HEAD        # contenu exact du dernier commit
git check-ignore journal.log  # confirme que la règle s'applique

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.

Catégorie	Exemples	Pourquoi exclure
Secrets	.env, clés API, certificats	poussés vers le remote = lisibles par tout accès au dépôt, souvent pour toujours (l'historique conserve chaque commit)
Dépendances	node_modules/	des milliers de fichiers reconstruisibles depuis package.json + lockfile ; alourdirait tout sans bénéfice
Artefacts de build	dist/, build/, *.min.js	régénérables par compilation ; les versionner doublerait chaque changement et créerait des divergences sources/binaires
Logs et données locales	*.log, bases SQLite de dev	volumineux, volatils, parfois sensibles
Environnement personnel	.DS_Store, .idea/, .vscode/	propres à votre machine, inutiles aux autres

Le test mental à retenir : « ce fichier peut-il être recréé depuis le dépôt ? » Si oui, il n'a rien à y faire. Sinon (code source, configuration partagée, documentation), il doit y être. Cas délicat à connaître : les secrets sont irrécréables ET interdits — leur place est hors Git, documentés par un fichier d'exemple sans valeurs (.env.example), sujet approfondi plus loin dans le cursus.

Commit 1 : l'ossature

mkdir recettes-app && cd recettes-app git init echo "# Gestionnaire de recettes" > README.md echo "Petit projet pour apprendre un historique propre." >> README.md git add README.md # fichier précis, pas add . git commit -m "Initialise le projet"

Commit 2 : les premières données

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"

Commit 3 : notes + règle d'ignorance

mkdir notes echo "Idée : filtre par ingrédient" > notes/idees.txt touch journal.log # le futur banni echo "*.log" > .gitignore git add .gitignore notes/ git status # journal.log n'apparaît NULLE PART ✓ git commit -m "Ignore les journaux et ajoute les idées"

Note sur le message du commit 3 : il mentionne deux choses (« ignore » + « ajoute »). Tolérable ici car c'est **une seule décision cohérente** (organiser le dossier notes) — le défi viserait vraiment à l'impossible si toute micro-tâche exigeait son commit. La règle reste : une *intention* par commit, pas une ligne par commit.

```bash
# Commits 4 et 5 : deux intentions, deux commits
echo "... (ajout de la crème)" >> recettes/pates.txt     # intention A
echo "Tarte tatin : ..." > recettes/tatin.txt            # intention B
git status          # les deux modifications sont listées ensemble...

git add recettes/pates.txt    # ...mais on n'en stage qu'une
git commit -m "Complète la recette des carbonara"

git add recettes/tatin.txt
git commit -m "Ajoute la tarte tatin"

C'est ici que la staging area prend tout son sens (souvenez-vous des trois zones) : elle permet de découper un état de travail brouillon en historique propre. Sans elle, ce découpage serait impossible.

Vérifications attendues

$ git status
On branch main
nothing to commit, working tree clean        ✓

$ git log --oneline
a9b8c7d Ajoute la tarte tatin
e6f5d4c Complète la recette des carbonara
c3b2a1d Ignore les journaux et ajoute les idées
b2a1z9y Ajoute les premières recettes
a1b2c3d Initialise le projet                  ✓ cinq intentions lisibles

$ git ls-files
.gitignore                                    ✓ présent
README.md
notes/idees.txt
recettes/gateau.txt
recettes/pates.txt
recettes/tatin.txt                            ✓ aucun .log

$ git check-ignore journal.log && echo "règle active"
règle active                                  ✓

Pourquoi c'est important

Un historique atomique permet de relire le projet comme une histoire (« quand ai-je ajouté X ? » → git log --oneline répond en dix secondes), d'annuler précisément (git revert <hash> annule UNE intention sans toucher au reste), et de collaborer sans noyer les autres sous des commits « divers ».

Et ce n'est pas qu'une question de goût : c'est ce même historique qui alimentera vos déploiements dans la suite du cursus (CI/CD) — chaque commit y sera testé, versionné, déployable. Un historique brouillon produit des versions brouillon ; un historique propre est la première pierre de la fiabilité. Vous venez de la poser.