Nous avons vu dans le chapitre précédent que l’historique de Git est d’une remarquable puissance. Cependant, au delà des aspects techniques, un usage efficace de Git passe par des messages de commit clairs et concis. Ils vous permettront de facilement vous y retrouver dans un projet et faciliterons la navigation dans l’historique, et in-fine, le debug.

Néanmoins, même avec d’importants efforts, nommer ses commits n’est pas chose facile.

Dans de telles conditions, on finit par ne plus trop s’y retrouver. Dès lors, l’usage de git log, git blame et autres perdent vite de leur intérêt.

Pour remédier à cela, de la même manière que de très nombreux projets ont des style guides, certains projets se dotent de normes afin d’imposer un style uniforme aux messages de commit.

C’est par exemple le cas pour Angular. Le projet dispose de règles très claires qui peuvent convenir à tous types de dépôt. En se basant sur les règles d’Angular, nous allons voir ce qui constitue un bon message de commit et la forme qu’il doit prendre.

Le commit parfait

Un bon message de commit doit permettre de savoir ce qui a changé et pourquoi. Le comment, c’est à dire la manière d’effectuer ces changements, n’a pas à être expliqué. La lecture du code et la mise en évidence des changements via un diff est explicite en soi.

Voici le format adopté par Angular.

<type>(<portée>): <sujet>

<description>

<footer>

On voit ici les différentes parties d’un commit et ce qu’elles doivent comporter. Voyons ces éléments dans le détail.

La première ligne comporte trois éléments : le type, la portée et le sujet. Voyons en quoi ils consistent.

Type du commit

Le type nous informe du type de commit. 9 types sont disponibles :

• build : changements qui affectent le système de build ou des dépendances externes (npm, make…)
• ci : changements concernant les fichiers et scripts d’intégration ou de configuration (Travis, Ansible, BrowserStack…)
• feat : ajout d’une nouvelle fonctionnalité
• fix : correction d’un bug
• perf : amélioration des performances
• refactor : modification qui n’apporte ni nouvelle fonctionalité ni d’amélioration de performances
• style : changement qui n’apporte aucune alteration fonctionnelle ou sémantique (indentation, mise en forme, ajout d’espace, renommante d’une variable…)
• docs : rédaction ou mise à jour de documentation
• test : ajout ou modification de tests

À cela s’ajoute revert. Ce dernier permet comme son nom l’indique, d’annuler un précédent commit. Dans ce cas, le message prend la forme suivante :

revert sujet du commit annulé hash du commit annulé

La partie affectée (scope)

C’est la deuxième élément de la première ligne. Il nous permet immédiatement de savoir quelle partie du projet est affectée. Par exemple pour un site de e-commerce, on pourrait avoir product, cart ou checkout.

Cet élément est facultatif. En effet, il n’est parfois pas pertinent.

Le sujet

Le sujet contient une description succinte des changements. En général, on se limite à 50 caractères. De nombreux outils avertissent d’ailleurs lorsque l’on dépasse la longueur maximale.

Pour adopter un style descriptif efficace, on utilise l’impératif présent : add, change, update, remove et non pas changed ou removed. add caching for better performance par exemple.

Personnellement, je suis le style guide et je ne mets pas de majuscule à la première lettre du sujet ni ne met de point à la fin. L’essentiel est surtout d’adopter une politique et de s’y tenir afin d’être cohérent.

Le corps du message

Beaucoup l’ignorent, mais les messages peuvent comporter un corps dans lequel on peut expliquer plus en détails la raison des changements. De même que pour le sujet, on utilisera l’impératif présent.

De nouveau, on explique ici la raison du changement et en quoi c’est nouvelle manière est différente de l’état précédent.

Le comment est visible directement dans le code. Par ailleurs, si le code est complexe, c’est le moment de penser à le commenter si ce n’est pas déjà fait !

Le footer du commit

De même que le corps du message, le footer est facultatif. On l’utilisera d’ailleurs moins souvent.

On réserve le footer aux breaking changes et on y référence aussi le ticket d’erreur que règlent les modifications le cas échéant.

Souriez

On voit de plus en plus l’usage d’emojis dans les commits. Gitmoji est un projet qui vise à définir un style guide quant à l’usage des emojis dans les commit.

Les emojis permettent de rapidement et visuellement transmettre du sens. De plus, un peu de fun dans les messages ne peut pas faire de mal.

En revanche, l’usage d’une palette d’emojis trop étendue dans les sujets peut mener à de la confusion car il n’est pas toujours évident que 🚀 a trait au déploiement.

Je n’utilise donc qu’un nombre d’icônes restreint qui correspondent aux différents types de commits.

Par ailleurs, je privilégie l’usage des emojis au format Unicode plutôt que d’utiliser les codes Markdown. Ainsi, les emojis sont affichés dans tous les environnements qui supportent Unicode – ce qui est beaucoup plus répandu que les environnements qui supportent le Markdown.

Pour me faciliter la tâche, j’utilise des hooks Git afin de remplacer automatiquement le code du type par l’emoji correspondant. Ainsi, lorsque je saisis mon message de commit, il est automatiquement transformé. Je tape :perf:(database) add … et le hook modifie mon message en ⚡(database) add ….

Étant donné que les hooks ne font pas partie du code commité, ils ne sont pas automatiquement mis en place lors d’un git clone.

Aussi, pour des projets collaboratif, on peut facilement ajouter l’installation des hooks au système de build. npm install peut par exemple tout à fait inclure l’ajout des hooks.

Par ailleurs, j’ai un alias dans mon bash afin de pouvoir ajouter les hooks à un repo existant d’une simple commande.

J’ai publié les hooks avec toutes les explications sur GitHub. N’hésitez donc pas à les inclure à vos projets !