infra / git-github
Commits et historique
Explication
Ce que vous allez apprendre
- Comprendre pourquoi un commit est un instantané, pas juste une liste de modifications
- Sélectionner précisément ce qui entre dans un commit avec
git add -p - Écrire un message de commit clair, à l'impératif, utile à toi-même dans six mois
- Explorer l'historique efficacement avec
git log --oneline --graph - Corriger le dernier commit sans polluer l'historique avec
git commit --amend
Dans quel contexte ?
Un développeur vient de corriger un bug d'affichage sur la page panier.html et, dans la foulée, a aussi commencé à expérimenter une nouvelle palette de couleurs pas encore validée. Avec git add ., les deux changements finiraient dans un seul commit confus. Avec git add -p, il ne committe que le correctif du panier sous le message "Fix cart total display on mobile", et garde l'expérimentation de côté pour plus tard.
L'unité de base de l'historique
D'abord, un commit est un instantané enregistré de ton projet à un instant donné, accompagné d'un message qui explique ce qui a changé et pourquoi.
Pourquoi c'est la brique fondamentale de tout le reste
C'est la brique de base de tout ce que Git permet ensuite : revenir en arrière, comparer deux versions, comprendre l'évolution d'un fichier.
Une règle simple pour des commits utiles
Plus les commits sont petits et cohérents, un commit = une idée logique, plus l'historique reste lisible plus tard, y compris pour toi-même six mois après.
Le réflexe le plus simple, mais imprécis
git add . ajoute tout ce qui a changé, ce qui est pratique mais peu précis : on risque d'enregistrer ensemble des choses qui n'ont rien à voir, comme un correctif de bug et une expérimentation en cours.
Une sélection beaucoup plus fine
git add -p permet une sélection morceau par morceau, "hunk" par "hunk", à l'intérieur même d'un fichier modifié. C'est l'outil du développeur soigneux qui veut des commits propres, pas juste "tout ce que j'ai tapé aujourd'hui".
Écrire un message qui sert vraiment
Un message de commit n'est pas de la paperasse administrative : c'est de la documentation vivante, consultée par tes collègues, ou toi-même, longtemps après.
La convention à suivre
La convention largement adoptée est une ligne de résumé courte à l'impératif, "Fix", "Add", pas "Fixed" ou "Added", suivie si besoin d'un corps expliquant le pourquoi du changement, pas seulement le quoi.
| Élément | Exemple correct | À éviter |
|---|---|---|
| Ligne de résumé | Fix null pointer in user validation | Fixed bug |
| Verbe | Impératif (Add, Fix, Remove) | Passé (Added, Fixed) |
| Corps du message | Explique le POURQUOI du changement | Répète juste le diff |
Bonne pratique
Utilise git add -p par défaut dès que tu as touché à plusieurs sujets dans la même session de travail. Un commit qui mélange un correctif de bug et une expérimentation en cours est presque impossible à annuler proprement plus tard si l'un des deux pose problème.
Corriger sans polluer l'historique
git commit --amend permet de corriger le tout dernier commit, un message mal formulé, un fichier oublié, sans créer un commit supplémentaire inutile.
Le piège à connaître avant d'utiliser amend
Cette commande réécrit l'historique. Elle est parfaitement sûre tant que le commit n'a pas encore été partagé vers un dépôt distant ; une fois partagé, la réécrire peut désynchroniser les collègues qui l'ont déjà chez eux.
Piège fréquent
Faire git commit --amend puis git push sur un commit déjà récupéré par un collègue force ce dernier à gérer un historique divergent à sa prochaine synchronisation. Réserve --amend aux commits que tu es certain de ne pas avoir encore partagés.
Maintenant que tu sais créer un historique propre en local, la leçon suivante s'attaque au passage de "local" à "partagé" : le push vers GitHub.
Commandes & code
Commit & historique
git add app.js # ajoute un fichier précis au staging
git add . # ajoute tout ce qui a changé dans le dossier courant
git add -p # ajoute INTERACTIVEMENT, hunk par hunk (précision chirurgicale)
git commit -m "Add hello world script"
git commit # ouvre l'éditeur configuré pour un message multi-lignes
# Raccourci : add + commit pour les fichiers DÉJÀ suivis (pas les nouveaux fichiers)
git commit -am "Fix typo in greeting message"# Bon message de commit : ligne de résumé courte, puis corps optionnel après une ligne vide
git commit -m "Fix null pointer in user validation
Guard against missing email field before calling .toLowerCase().
Fixes crash reported in issue #142."# Explorer l'historique
git log
git log --oneline # une ligne par commit
git log --oneline --graph --all # visualise les branches sous forme de graphe ASCII
git log -p -- app.js # diff complet de chaque commit touchant app.js
git log --author="Ada"
git log --since="2 weeks ago" --until="yesterday"
git log -n 5 # les 5 derniers commits
# Voir le contenu exact d'un commit
git show a1b2c3d# Modifier le DERNIER commit (message ou contenu) - jamais après un push public !
git commit --amend -m "Fix null pointer in user validation (v2)"
git add fichier-oublie.js
git commit --amend --no-edit # garde le même message, ajoute le fichier oubliéRésumé
git add -ppermet de committer précisément, hunk par hunk, plutôt que tout d'un coup.- Message de commit : résumé court à l'impératif + corps optionnel expliquant le "pourquoi".
git log --oneline --graph --allest le meilleur point de vue rapide sur l'historique.git commit --amendréécrit le dernier commit : à réserver aux commits non partagés.
Exercices pratiques
Mission : nettoyer un commit avant qu'il ne soit trop tard
Objectif : Reconstituer un commit propre à partir d'un fichier modifié à plusieurs endroits, et diagnostiquer les risques d'un amend mal placé.
Contexte
Sur boutique-api, le fichier pricing.js contient à la fois un correctif de bug urgent et une expérimentation de prix non validée, mélangés dans les mêmes lignes modifiées. Par ailleurs, un collègue vient de faire git commit --amend puis git push --force sur un commit que toute l'équipe avait déjà récupéré la veille.