Le problème
Un historique rempli de « fix », « wip » ou « changes » est inutilisable : impossible de comprendre ce qui a changé, ni de retrouver le commit à annuler en cas de régression.
Le format
<type>(<portée>): <description>
[corps optionnel]
[pied optionnel]Exemple :
feat(content): add git presentationLes types usuels
| Type | Usage |
|---|---|
feat | Une nouvelle fonctionnalité ou un nouveau contenu |
fix | Une correction de bug |
docs | Documentation seule |
test | Ajout ou correction de tests |
refactor | Changement de code sans effet fonctionnel |
perf | Amélioration de performance |
ci | Pipeline d'intégration continue |
chore | Tâches diverses (dépendances, configuration) |
Les règles d'or
- Une description courte, à l'impératif, sans point final.
- La portée (
content,ci,ui) situe le changement. - Un commit = une intention.
Pourquoi un commit par intention ?
C'est ce qui rend le rollback possible. Si chaque article ajouté fait l'objet de son propre commit, on peut retirer l'un d'eux sans toucher aux autres :
git revert <hash>git revert crée un nouveau commit qui annule le premier : l'historique reste intact, ce qui est sûr même sur une branche partagée.
Changement cassant
Un ! après le type, ou un pied BREAKING CHANGE:, signale une rupture de compatibilité :
feat(api)!: remove legacy endpoint
BREAKING CHANGE: /v1/posts is no longer available.Les bénéfices
- Revues plus rapides : le message annonce l'intention.
- Journal des modifications généré automatiquement.
- Versionnement sémantique déductible (
feat→ mineure,fix→ correctif).
À retenir
Une bonne convention coûte quelques secondes par commit et fait gagner des heures lors d'une enquête ou d'un rollback.