Accueil Technologies Conventional Commits : détails & exemples pratiques
Conventional commits

Conventional Commits : détails & exemples pratiques

par Jérémy PASTOURET
Publié : Mis à jour le

Dans mon précédent article, vous trouverez les bases des Conventional Commits. Dans ce nouvel article, je vous propose d’aller plus loin en vous présentant les différents types de commits possibles. Enfin, pour terminer, j’ai écrit quelques exemples clairs pour illustrer tout ça.

Rappel de la structure d’un commit avec cette convention

<type>[option: la portée (scope)]: <description>

[option: le corps (body)]

[option: le bas de page (footer)]

Les différents types de base des Conventional Commits

bannière modernes

Un type peut prendre différentes valeurs :

  • fix : la réparation d’un bug. Avec SemVer, cela correspond à une version de type PATCH.
  • feat : l’ajout d’une ou plusieurs fonctionnalités. Avec SemVer, on parle de version MINOR.

Variante avec Angular

Angular.js, un framework front-end, propose des types supplémentaires. Il n’y a aucune obligation à les utiliser. Tout dépend de l’équipe et du projet.

  • build : changement dans la manière de compiler, d’utiliser la librairie sous différents systèmes d’exploitation ou ajout de dépendances externes.
  • ci : changement dans la manière de lancer des tests / scripts automatisés (avec Travis, Circle…).
  • docs : changement concernant la documentation.
  • perf : améliore la performance du projet.
  • refactor : améliore la compréhension ou le contenu du code. Cependant, aucun bug n’est corrigé, ni aucune fonctionnalité ajoutée.
  • style : changement qui n’affecte pas la manière de comprendre le code. Cela peut être une question de formatage, d’espace, de retour à la ligne, de tiret dans les noms…
  • test : ajout de tests ou mises à jour de scripts de tests.

Les descriptions avec les Conventional Commits

Bannière problème

Lorsqu’on répare des bugs ou que l’on ajoute du code, il arrive que ces changements impactent les projets qui utilisent cette librairie, framework, API… c’est ce qu’on appelle Breaking Change. Avec SemVer, on parle de version de MAJOR lorsque de tels changements interviennent.

Il est donc important de les mentionner dans la partie body (description du commit). Il est aussi très important d’écrire les termes en majuscule :

BREAKING CHANGE

Exemples de commits appliquant les Conventional Commits

Bannière développeurs

Voici un commit simple

docs: ajout de commentaires dans la création de PDF

Un commit avec une portée précise (scope)

feat(lang): ajout de l'Anglais

Un commit avec un ( ! ) indiquant la présence d’un BREAKING CHANGE

feat!: Ajout d'une gestion des droits d'accès

BREAKING CHANGE: Pour créer un nouveau compte, il faut ajouter un champ permettant de choisir le role.

Enfin, un commit avec plusieurs lignes dans le corps (body) et un bas de page (footer)

fix: correction de quelques bugs mineurs

Pour plus d'information, rendez-vous dans le ticket du bug

concernant les problèmes de typages.

Reviewed-by: jenovateurs
Refs #1485

Conclusion

Bannière conclusion

Toutes ces règles sont modulables en fonction des équipes et des projets. Par exemple, Angular impose des règles strictes concernant les commits, Vue.js a quant à lui d’autres règles…

D’ailleurs, si vous souhaitez consulter les Conventional Commits de base, vous pouvez les retrouver sur le site suivant : conventionalcommits.org

L’article suivant vous présente un premier outil intéressant à utiliser avec cette convention d’écriture.

Et vous, que pensez-vous de cette convention d’écriture ? Allez-vous l’utiliser dans vos prochains projets ? Ou même l’appliquer dans vos projets en cours ?

Vous pourriez aussi aimer

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.