Commits
& messages
L’historique raconte comment le code a évolué. Chaque commit en est une étape, et son message doit dire pourquoi.
Un historique qu’on peut relire, parcourir avec git log, annuler commit par commit et exploiter pour générer les notes de version.
Un commit, une étape logique
Un bon commit est atomique :
- il traite un seul sujet : une fonctionnalité, un correctif ou un refactoring, pas les trois ;
- il compile et passe les tests, pour qu’on puisse s’y arrêter, le livrer ou l’annuler seul ;
- il ne mélange pas reformatage et changement de logique, sinon la revue devient impossible ;
- il reste de taille raisonnable : si le message a besoin de « et » pour tout décrire, c’est probablement deux commits.
Pour composer un commit propre à partir de modifications mélangées, indexez morceau par morceau :
git status
git add -p # choisir les morceaux à indexer, un par un
git diff --staged # relire exactement ce qui sera commité
git commit
Le format des messages
Nous suivons la convention Conventional Commits :
type(portée): description courte à l'infinitif
Corps facultatif : le pourquoi du changement, le contexte,
les choix écartés. Lignes de 72 caractères maximum.
Refs: CMA-142
- Titre : 72 caractères maximum, idéalement moins de 50, en minuscules, à l’infinitif, sans point final.
- Ligne vide entre le titre et le corps : de nombreux outils s’en servent pour séparer les deux.
- Corps : explique pourquoi, le diff montre déjà le comment.
- Pied : référence du ticket (
Refs: CMA-142,Closes #23) et, le cas échéant,BREAKING CHANGE:suivi de la description de la rupture.
Les types
| Type | Usage |
|---|---|
feat | Nouvelle fonctionnalité |
fix | Correction de défaut |
docs | Documentation seule |
style | Mise en forme sans effet sur le comportement |
refactor | Restructuration sans changement de comportement |
perf | Amélioration des performances |
test | Ajout ou correction de tests |
build | Système de build, dépendances (Maven, npm) |
ci | Pipelines GitLab CI |
chore | Maintenance diverse |
revert | Annulation d’un commit précédent |
La portée, facultative, désigne le module concerné : feat(stock), fix(auth), ci(gitops).
Bons et mauvais exemples
| À éviter | Préférer |
|---|---|
fix | fix(vente): arrondir le total TTC au franc CFA |
modifs | refactor(stock): extraire le calcul du seuil d'alerte |
fixed some errors | fix(auth): renouveler le jeton JWT avant expiration |
WIP | feat(ordonnance): ajouter l'export PDF |
Merge branch 'develop' of https://git.agitex.fr/... | Pas de commit de merge : se mettre à jour avec git pull --rebase |
Exemple complet :
fix(vente): arrondir le total TTC au franc CFA
Les totaux étaient arrondis au centime, ce qui créait un écart avec
les montants encaissés en caisse. L'arrondi se fait désormais à
l'unité, après application de la TVA, conformément à la demande
du service comptable.
Refs: CMA-187
Ce qu’on ne commite jamais
| Interdit | Pourquoi | À la place |
|---|---|---|
Mots de passe, jetons, clés privées, .env | Ils restent dans l’historique, même supprimés ensuite | Variables CI masquées, secrets Kubernetes, .env.example sans valeurs |
target/, dist/, node_modules/ | Artefacts régénérables, volumineux, sources de conflits | .gitignore |
Fichiers d’IDE (.idea/, *.iml) | Propres à chaque poste | .gitignore global |
| Dumps de base, exports de données réelles | Données personnelles ou de santé, poids | Jeux de données anonymisés et versionnés à part |
| Gros binaires | Alourdissent définitivement le dépôt | Registre d’artefacts, ou Git LFS si indispensable |
:::danger Un secret commité est un secret compromis Le supprimer dans un nouveau commit ne suffit pas : il reste dans l’historique et dans tous les clones. Révoquez-le immédiatement, puis suivez la procédure de Sécurité du dépôt. :::
Corriger avant de publier
Tant que les commits ne sont pas poussés, ils peuvent être retravaillés librement :
git commit --amend # corriger le dernier commit (contenu ou message)
git commit --fixup <sha> # préparer la correction d'un commit plus ancien
git rebase -i --autosquash origin/develop
Une fois poussés sur une branche partagée, ils ne se modifient plus : voir Git avancé.
Vérifier automatiquement
Un hook commit-msg peut refuser les messages hors format avant même le commit. Côté Angular, commitlint et husky s’installent dans le projet :
npm install --save-dev @commitlint/cli @commitlint/config-conventional husky
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
npx husky init
echo 'npx --no -- commitlint --edit "$1"' > .husky/commit-msg