Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage.
Je m'appelle Nicolas Bondin-Bernard et aujourd'hui, on va découvrir une convention pour écrire
des bons messages de comites qui contiennent toutes les informations dont on a besoin
quand on va relire un historique guide.
Alors la force de guide, c'est bien évidemment de stocker et versionner toutes les modifications
d'un code source au fil du temps et ça permet de garder donc un historique et de pouvoir
revenir à une version antérieure s'il y a besoin ou même sans revenir à une version,
en tout cas comprendre les modifications qu'il y a eu et ce qui a pu poser problème éventuellement
et ce qu'il faudra réparer par la suite.
Alors comme on ne parcourt pas un historique guide juste pour le fun, en général on le
fait pour retrouver quelque chose, retrouver un point dans le temps, en tout cas un point
dans la version du code, et bien qu'on cherche parce qu'on a besoin de retrouver cette étape-là.
Et donc on peut le faire que si on comprend ce qu'on parcourt, si tous vos comites portent
le même nom ou juste un message prédéfinie ou peu importe, ça sera vraiment très difficile
de retrouver ce que vous cherchez.
Et c'est là un petit peu qu'on se rend compte que bien savoir écrire des messages
de comites, c'est en réalité une facette hyper importante de la gestion d'un projet
de développement web, enfin développement web, développement informatique en général.
Alors chaque comite peut contenir un grand nombre d'infos importantes et donc c'est
pour ça que c'est nécessaire de trouver ou de suivre une structure de messages qui
soit à la fois facilement compréhensible, pas trop difficile à écrire parce que si
ça prend des heures à écrire, c'est sûr qu'on ne va pas le faire ou alors ça fera
perdre une productivité de dingue et qui hiérarchise bien les informations.
Et heureusement, il existe une convention qui coche toutes ces cases-là et c'est
ce qu'on appelle des conventional comites.
Donc conventional comites, ça permet d'avoir un message de comites idéal qui contient
toutes les informations justement comme je disais qui sont nécessaires la bonne compréhension
d'un humain parce que c'est vous ou quelqu'un d'autre qui va lire cette historique.
Et donc ça va contenir le type de changement, une nouvelle fonctionnalité par exemple,
qu'est-ce qu'on a apporté au code ? Est-ce que c'est une suppression ? Est-ce que c'est
une modification ? Est-ce que voilà.
La portée de ce changement-là, quelle partie du code a été modifiée ? Est-ce que c'est
un module particulier ou non ? La description de ce changement, une description basique
évidemment, est éventuellement le numéro du ticket ou Dishu qui a été corrigé dans
le cas où ce serait la correction d'un bug ou alors si vous faites votre tracking de
projet grâce à l'etiquette des Dishu.
Et le format conseillé par cette convention, c'est de commencer par le type.
Donc le type, ça va être par exemple fixe si c'est une correction de bug.
Ensuite, on va avoir entre parenthèses le module qui est concerné, on va dire le module
utilisateur par exemple.
Ensuite, on va faire deux points, le message de comites.
Donc par exemple authenticate user with email instead of username.
Je prends vraiment un truc au hasard.
Et en dessous, à la ligne, on va avoir le numéro de Dishu, donc issue hashtag 132 par exemple.
Il faut savoir que la specification contient 15 règles précises à suivre comme par exemple
le type de comites.
Là, on a dit que le comite était le type fixe, mais on a fit for feature, donc fixe.
On a refactor build core, pour qu'on...
Core C-H-O-R-E, pour qu'on sait quelque chose, on va dire un peu de nettoyage.
CI, docs, style, test, etc.
Vous pouvez retrouver toutes ces informations-là et toutes ces règles sur la documentation
officielle tout simplement que je vous mettrai en note de l'épisode.
Le site simplement conventionnelcommites.org.
Et en bonus, cette convention vous permet de passer les messages de comites assez facilement
avec une machine et donc par exemple de générer automatiquement des change logs.
Alors ça, ça peut être très niche comme utilisation, mais au moins quand vous respectez
et toute l'équipe respecte une convention de comites, ça vous permet de faire de nouvelles
choses.
Alors, à titre très personnel, j'ai pendant longtemps, d'ailleurs je l'utilise encore
un peu de temps en temps, utiliser une variante de cette convention qui est juste légèrement
plus concise, parce que j'avoue que je mets un petit peu un point d'honneur à ce que
mes messages de comites y tiennent tous sur une ligne.
Ça permet de les identifier et de lire l'entierté du comite très, très vite.
Donc je faisais un petit peu différemment, mais je faisais donc le message qu'on tenait
au début le type, comme on a dit tout simplement de modification, entre crochet et en majuscule.
Donc par exemple, pareil, entre crochet fixe en majuscule.
Ensuite, j'utilise évidemment le scope, donc par exemple user.
Entre parenthèse le numéro de l'ishio et ensuite un tiré et le message complet de
ce qu'a été fait.
Donc c'est vraiment plutôt conseiller d'utiliser les formats conventionals comites, mais en
vrai vous êtes libre d'utiliser celle-là aussi ou une variation, parce qu'en réalité
il vaut mieux une convention qui est respectée par tous les membres de l'équipe, même si
elle n'est pas standard, plutôt que pas de convention du tout, ou alors évidemment
plusieurs conventions qui sont suivies par différents membres de l'équipe.
Donc ça, il vaut mieux effectivement avoir quelque chose de non standard mais qui est
suivi par tout le monde.
Et on ne va même pas parler de comites en messages, parce que ça reste une hérésie
et de quoi se tirer les cheveux pendant pas mal d'années.
J'espère que cet épisode vous a été utile, j'espère que vous ne connaissiez pas forcément
justement le conventional comites.
Je vous invite à aller faire un tour sur la documentation vraiment qui sera dans les
notes de l'épisode.
Et moi je vous donne rendez-vous la semaine prochaine pour un prochain épisode du podcast.
Mais avant de vous laisser, je vous rappelle si vous n'avez pas écouté l'épisode de
la semaine dernière ou pas jusqu'au bout, parce qu'il est pas bien, qu'on vient de
sortir une offre pour les écoles.
Donc si jamais vous voulez offrir des licences Code Garage à vos étudiants, on a tout prévu.
Vous allez sur la page tarif de Code Garage et vous verrez qu'il y a une section spéciale
pour les écoles avec un tarif qui est hyper préférentiel et en plus une offre promotionnelle
qui est jusqu'au 31 septembre pour préparer la rentrée.
Vraiment, font saisie et si vous avez la moindre question, n'hésitez pas à envoyer un petit
mail.
Je vous donne rendez-vous la semaine prochaine pour un prochain épisode.
Salut !