Session 14 : Git Best Practices : écris des commits que tu comprendras encore plus tard

Tu sais taper des commandes Git. Ton code est sur GitHub. Mais il y a une différence entre « utiliser Git » et « bien utiliser Git ».

Cette session parle des habitudes que les développeurs expérimentés appliquent chaque jour. Pas de nouvelles commandes, mais des règles plus précises. À la fin, tu écriras des commit messages qui te serviront encore dans un an, et tu travailleras avec une stratégie de branching qui garde ton projet clair.

Ce que tu vas apprendre aujourd’hui

Comment écrire un commit message qui dit quelque chose
Trois règles simples pour le branching
Ce qu’est git stash et quand l’utiliser
La règle du pull avant le push

Partie 1 : Des commit messages qui disent quelque chose

Un mauvais commit message ressemble à ça :

git commit -m "fix"
git commit -m "update"
git commit -m "trucs modifiés"

Dans trois mois, tu regardes en arrière. C’était quoi « fix » ? Quels « trucs » ? Tu ne le sais plus. Tu dois fouiller dans le code pour retrouver ce qui s’est passé. C’est du temps perdu.

Le bon commit message : 3 parties

Un commit message professionnel a trois parties :

1. Un résumé court (72 caractères max)

Écris en anglais. Commence par un verbe au présent. Ça s’appelle l’« imperative mood » : comme si tu donnais un ordre à ta base de code. Pense : « Add », « Fix », « Remove », « Update », « Refactor ».

Add highscore tracking
Fix star spawning off-screen
Remove unused collision code

2. Une ligne vide

3. Une explication plus longue (optionnel, si c’est utile)

Add highscore tracking

Sauvegarde le meilleur score dans highscore.txt. Le score est
mis à jour après chaque game-over. Le fichier est créé s'il
n'existe pas encore.

Ça remplace l'ancienne méthode où le score restait seulement
en mémoire et se perdait à la fermeture du jeu.

L’explication détaillée raconte pourquoi tu as changé quelque chose, pas seulement quoi. Le code lui-même montre déjà le « quoi ». C’est le « pourquoi » dont tu auras besoin dans trois mois.

Les règles de commit message en un coup d’œil

À faire	À ne pas faire
“Add player health bar”	“added health bar thing”
“Fix collision detection on left wall”	“fix”
“Remove debug print statements”	“cleanup”
72 caractères max pour le titre	Une histoire entière dans le titre
Présent, anglais	Passé (« added », « fixed »)

Pourquoi l’anglais ? Parce que presque tous les projets open source utilisent l’anglais. Le code est international. Ton code Python aussi, tu l’écris en anglais (def calculate_score). Tes commit messages suivent la même langue.

Pourquoi le présent ? Un commit décrit ce que cette modification fait, pas ce que toi tu as fait. « Add feature » (ce commit ajoute une feature), pas « Added feature » (j’ai ajouté une feature un jour). Git lui-même utilise le présent : Merge branch 'feature', pas Merged.

Des commits multi-lignes dans le terminal

Tu peux écrire un commit message sur plusieurs lignes en ne fermant pas les guillemets :

git commit -m "Add highscore tracking

Sauvegarde le meilleur score dans highscore.txt. Le fichier est
créé automatiquement au premier game-over."

Attention : tu ne tapes le guillemet fermant qu’à la dernière ligne. Tout ce qu’il y a entre les deux fait partie de ton message.

Quand est-ce que tu committes ?

Committe souvent. Committe petit.

Pas : trois heures de travail, un seul commit énorme avec 47 fichiers modifiés. Oui : un commit toutes les 15 à 30 minutes, chaque fois qu’un petit morceau logique est fini.

Règle de base : si ton commit message contient « et », ton commit est trop gros. « Add highscore tracking et fix menu bug et update sprites » → ça doit être trois commits séparés.

Des petits commits facilitent :

Comprendre ce qui a changé et quand
Annuler une modification précise sans casser le reste
Résoudre des merge conflicts (petits morceaux = moins de conflicts)

Partie 2 : Le branching : trois règles simples

Tu sais déjà comment créer des branches (session 12). Maintenant : quand et pourquoi.

Règle 1 : `master` marche toujours

La branche master, c’est ta vitrine. Quelqu’un qui clone ton repo doit pouvoir lancer ton code sans message d’erreur. master ne contient jamais du travail à moitié fini.

Pas ok sur master : du code avec # TODO: encore à finir, des fonctions en commentaire, des expériences que tu « répareras plus tard ».

Ok sur master : du code qui marche. Point.

Règle 2 : Une feature, une branche

Une branche fait exactement une chose. Pas plus.

Bien : feature/player-health-bar
Mauvais : feature/health-bar-and-menu-and-sound-effects

Si, en travaillant sur une feature, tu penses : « Oh, je peux aussi réparer ce bug de menu vite fait » : stop. Fais une nouvelle branche pour le bugfix. Merge-la d’abord. Ensuite, continue ta feature.

Règle 3 : Les branches ont une vie courte

Une branche qui existe depuis plus de quelques jours devient un problème. master change entre-temps, et ta branche prend du retard. Plus tu attends pour merger, plus le risque de merge conflicts augmente.

Merge ta branche dès que la feature est finie. Pour les petites choses (un bugfix de 10 minutes) : tu n’as peut-être même pas besoin d’une branche séparée.

Nommer les branches

Donne aux branches des noms que tu comprendras encore dans une semaine :

feature/highscore-tracking
bugfix/star-spawn-offscreen
experiment/particle-effects

Le préfixe (feature/, bugfix/, experiment/) dit tout de suite quel genre de travail se trouve dans cette branche. C’est une convention, pas une obligation technique, mais ça aide.

Partie 3 : Des commandes de workflow pratiques

`git stash` : mettre du travail de côté

Imagine : tu travailles sur une branche feature. Ton code est à moitié fini. Tu veux passer vite fait sur master pour un bugfix, mais tu ne veux pas committer ton travail à moitié fini. C’est pour ça que git stash existe :

git stash

Git garde toutes tes modifications de côté et remet ton working directory au dernier commit. Tu peux maintenant switcher, faire le bugfix, committer, et revenir :

git switch master
# ... faire le bugfix, committer ...
git switch feature-branch
git stash pop

git stash pop ramène tes modifications gardées de côté. Tout est de nouveau comme tu l’as laissé : à moitié fini, mais bien gardé.

`git pull --rebase` : un historique plus propre

Normalement, git pull fait un merge. Ça crée un commit de merge en plus. Parfois tu n’en veux pas ; tu veux une ligne droite de commits sans branches.

git pull --rebase

Ça récupère les derniers commits et met tes commits locaux par-dessus, comme si tu les avais faits après les commits du remote. Le résultat, c’est un historique linéaire : pas de merge-commits qui disent seulement « Merge branch ‘master’ ».

Attention : n’utilise --rebase que sur des branches que tu es seul à utiliser. Sur des branches partagées, un simple git pull (merge) est plus sûr.

La règle du pull avant le push

Avant de faire git push :

git pull

Toujours. Même si tu penses que personne d’autre n’a pushé. Ça prend une seconde et ça évite que GitHub refuse ton push avec « Updates were rejected because the remote contains work that you do not have locally. »

Cette règle compte surtout quand tu travailles à plusieurs. Si tu es le seul à travailler sur un repo, le risque est plus petit, mais l’habitude vaut de l’or.

Partie 4 : Le `.gitignore` qu’il te faut toujours

Chaque projet a des fichiers qui n’ont rien à faire dans Git. Ton .gitignore est ta première ligne de défense contre un mot de passe commité par accident.

.gitignore minimal pour un projet Python :

# Python
__pycache__/
*.pyc
*.pyo

# Environnement virtuel
venv/
.venv/

# Variables d'environnement (contiennent souvent des mots de passe/clés)
.env

# Ton éditeur
.vscode/
.idea/
*.swp
*.swo

# Fichiers du système
.DS_Store
Thumbs.db

Pourquoi ignorer __pycache__/ ? Ce sont des fichiers Python compilés que ton programme crée automatiquement. Ils sont différents selon la version de Python et selon l’ordinateur. Les mettre dans Git, ça ne fait que du bruit.

Pourquoi ignorer .env ? Les fichiers .env contiennent souvent des clés secrètes, des API keys, des mots de passe de base de données. Ceux-là ne doivent jamais, mais alors jamais, aller dans Git.

Showcase

Montre à un coach et à un buddy :

Tes 5 derniers commits, avec de bons commit messages.
Ton fichier .gitignore.
Un nom de branche qui suit la convention du préfixe feature/.

À la prochaine !

« Maintenant tu travailles avec Git comme un pro. Mais il reste un concept que chaque équipe utilise : la pull request. Ton code est prêt, mais avant qu’il arrive dans master, quelqu’un d’autre doit l’approuver. Comment ça marche ? La prochaine fois : les pull requests, le mur de review par lequel chaque modification doit passer. »

À emporter chez toi

Facile : réécris les commit messages de tes 5 derniers commits. Utilise les règles de cette session.
Moyen : crée une branche avec le préfixe feature/, travaille dedans, merge-la et supprime-la. Fais pareil pour une branche bugfix/.
Difficile : utilise git stash pour garder du travail à moitié fini, switch sur master, fais un fix rapide, push, et reviens sur ta feature avec git stash pop.
Très difficile : crée une situation où git pull échoue (clone ton repo dans deux dossiers, fais un commit différent dans les deux, push le premier, et essaie de pusher le second). Résous-le : git pull, répare le merge conflict, et seulement après, pushe.