GIT_WORKFLOW — la discipline Git du projet

Git fait partie de l'apprentissage, pas de l'intendance. Ce fichier est la référence unique : quand committer, quoi committer, comment nommer, comment réparer. (La leçon 00-3 explique les concepts ; ici c'est le règlement.)

Les trois étages (à comprendre une fois pour toutes)

Sauvegarder n'est PAS committer. Committer n'est PAS pousser. Un travail seulement sauvegardé peut être perdu ; un travail seulement commité peut être perdu avec la machine ; un travail poussé est en sécurité.

Le cycle de base (à faire des dizaines de fois par semaine)

git status                     # 1. TOUJOURS d'abord : qu'est-ce qui a changé ?
git add <fichiers précis>      # 2. choisir ce qui entre dans la photo
git status                     # 3. vérifier la zone de staging
git commit -m "type: message"  # 4. la photo
git push                       # 5. en fin de session, ou après un jalon

• git status : avant CHAQUE add et CHAQUE commit. C'est gratuit et ça évite 90 % des commits ratés.
• git add : préfère nommer les fichiers (git add lessons/level-01-bases/exercices/mes-reponses/ex-01-1-a.py) plutôt que git add . — tu sais alors exactement ce que contient le commit. git add . est acceptable quand git status ne montre QUE des fichiers liés au même sujet.
• git push : obligatoire en fin de chaque session de travail, même courte.

Quand committer (règles du projet)

Un commit = un sujet. Si ton git status mélange des exercices du niveau 2 et une leçon du niveau 3, fais deux commits. Un commit qui a besoin de « et » dans son message est probablement deux commits.

Messages de commit

Format : type: description en anglais, à l'impératif, < 60 caractères.

Types utilisés dans ce projet :

Mauvais messages (interdits) : update, wip, changes, aaa, fix stuff. Un bon message répond à : « si je lis l'historique dans 2 mois, est-ce que je comprends ce que ce commit apporte ? »

Revenir en arrière proprement

Du moins destructif au plus destructif — toujours essayer dans cet ordre :

git restore <fichier>          # annuler les modifs NON commitées d'un fichier
git restore --staged <fichier> # sortir un fichier du staging (garde les modifs)
git revert <hash>              # créer un commit inverse (historique préservé) ✅
git reset --soft HEAD~1        # défaire le dernier commit, GARDER les modifs
git reset --hard HEAD~1        # ⚠️ défaire ET détruire les modifs — jamais sur
                               # du travail poussé, jamais sans git status avant

Règle : sur tout ce qui a été poussé, on utilise revert (jamais reset). En cas de doute : git status, puis demander à Claude avec le contexte complet (prompt « SOS Git » dans PROMPTS.md) — ne pas taper des commandes au hasard.

Branches

Pour ce projet d'apprentissage, tout se passe sur main : tu es seul, le risque de conflit est nul, et la simplicité prime. Les branches deviennent utiles au niveau 10 (projet final) : une branche par fonctionnalité (feature/export-csv), fusionnée dans main quand elle marche. La leçon 10 couvrira ce workflow. Avant ça, ne t'en sers pas — c'est de la complexité sans bénéfice à ce stade.

Routine Git quotidienne

1. Début de session : git status (la session précédente est-elle propre ?) puis git pull (inutile seul sur une machine, vital le jour où tu en as deux).
2. Pendant : commits au fil des règles ci-dessus.
3. Fin de session : git status → tout committer proprement → entrée de journal → git commit -m "journal: ..." → git push → vérifier sur github.com que le push est bien là (les 2 premières semaines).

Historique propre : les 5 commandements

1. git status avant toute commande qui modifie l'état.
2. Un commit = un sujet, un message clair.
3. Committer souvent (petits commits > gros commit fourre-tout du soir).
4. Ne jamais committer : secrets, mots de passe, gros fichiers générés (website/dist/, __pycache__/ — le .gitignore du repo s'en charge).
5. Push en fin de session, sans exception.