Nommer ses commits dans git

Tu connais ce moment : tu viens de coder quelques lignes de code et tu dois maintenant le “push” sur ta plateforme GIT préféré et là LA question : quel nom je donne à ce commit ?

Source

Attention je parle ici de convention car oui, tu fais ce que tu veux mais l’idée quand tu donnes un petit nom à ton commit est de permettre à n’importe que de comprendre ce que tu as fais en quelques mots.

Personnellement, j’essaie d’appliquer la Conventional Commits. Pas la peine d’aller regarder mes repos sur github pour vérifier si c’est le cas, je plaide coupable d’avance. Pour mes projets personnels ce n’est pas toujours le cas mais dans le cadre professionnel, ca me parait nécessaire dans la mesure où il s’agit d’un travail d’équipe.

Alors ca ressemble à quoi cette convention ?

Voici à quoi elle ressemble :

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

2 éléments obligatoires (type et description) et 3 optionnels (scope, body et footer).

Type

Le type du commit, c’est ce qui caractérise le commit. Normalement avec les 9 types suivants vous devriez couvrir l’ensemble des possibilités.

• build : changements qui affectent le système de build ou des dépendances externes (npm, composer…)
• ci : changements concernant les fichiers et scripts d’intégration ou de configuration (Travis, CircleCI…)
• docs : rédaction ou mise à jour de documentation
• 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…)
• test : ajout ou modification de tests

Scope

Optionnel, l’idée du scope est de préciser le type définit précédemment. On retrouvera par exemple une précision sur le domaine impacté (authentification, produit ou panier dans un ecommerce, article ou commentaire dans un blog, …)

Description

Le sujet du commit en 50 caractères. Oui, il faut aller à l’essentiel.

Body

Optionnel, le body est là pour préciser ce qui n’est pas explicite dans la description.

Footer

Optionnel, le footer peut servir a indiqué des références (une issue sur Github/Gitlab, un ticket sur Jira, …)

Un exemple ?

docs(changelog): Add 1.0.1 release note

Il faut un peu de temps pour que cette convention devienne un réflexe mais quand tu regarderas ton historique GIT, tu verras, ça fait plaisir :)

Dernière chose, si tu as envie d’apporter une petite touche de bonne humeur, regarde du côté de gitmodji