En tant que développeur, on a tous un jour rédigé un commit de la sorte :
git commit -m "WIP"
git commit -m "test"
La plupart du temps, pas de soucis, ces commits tombent dans les tréfonds de l’historique GIT et personne ne les reverra jamais. Jusqu’au jour ou la prod est en feu et qu’il faut retrouver le code qui provoque cette pagaille. Aie, c’est pas pratique de retrouver du code quand tous les commits sont mal nommé.
Aujourd’hui, je vais vous donner une solution au problème de nommage des commits que j’utilise quotidiennement et qui me facilite la vie !
Conventional commits c’est quoi ?
Conventional commits comme son nom l’indique est une convention qui permet de structurer la rédaction des commits GIT.
Comment ça marche ?
Voici à quoi ressemble un commit suivant cette convention
<type>(scope): <description>
Les types
Le type permet de spécifier globalement les modifications qui ont été apportées. Voici la liste des types possibles :
- feat : ajout d’une fonctionnalité
- fix : fixe d’un bug
- docs : changement de la documentation
- style : changement qui n’affecte pas le sens du code comme l’ajout d’une tabulation ou d’un point-virgule
- refactor : un changement qui n’ajoute pas de fonctionnalité et qui ne fixe pas de bug
- perf : amélioration des performances
- test : ajout d’un test ou correction d’un test existant
- build : changement qui affecte le système de build ou les dépendances
- ci : changement qui affecte la fichier de configuration ou les scripts de CI
- chore : autres changements que src et les tests
- revert : enlève un commit
Le scope
Le scope est une partie optionnel du message de commit. Il permet de spécifier l’endroit du code qui a été modifié. Cela peut être le nom de la fonctionnalité ou le nom du dossier dans lequel les fichiers sont modifiés.
En général, c’est grâce au scope que l’on peut facilement retrouver une modification de code qui nous intéresse.
On peut ajouter un point d’exclamation juste après le scope pour indiquer que les changements apportés par le commit introduisent un breaking change.
La description
La description a pour but de donner des informations complémentaires du scope. En lisant la description, le développeur doit saisir le sens global du changement apporté par le commit.
Exemples
feat: allow provided config object to extend other configs
feat(api)!: send an email to the customer when a product is shipped
Voici la documentation officielle de conventional commits
Top comments (0)