Norme à suivre pour la rédaction des messages de commit git

Question

Je me retrouve à gérer un très grand nombre de fichiers (plus de 60 mais moins de 70) et mes messages de validation suivent jusqu'à présent ce modèle : quand j'ai ajouté quelque chose comme sur layout.css mon message de validation est "ajouté quelque chose sur le fichier layout.css" et lorsque je supprime quelque chose, mon message de validation est le suivant "supprimé quelque chose du fichier layout.css" .

Quelques fichiers plus tard, je regarde mon flux de commits et ajouté... y retiré... les messages dominent. Parfois, je ne me souviens pas de ce que j'ai enlevé ou ajouté en layout.css car je fais beaucoup de changements à la fois et j'ai du mal à trouver un message de livraison approprié.

Existe-t-il une norme que je devrais suivre pour m'aider à rédiger mes messages de validation ?

Answer 1

Lorsque vous vous contentez de décrire ce que vous avez fait (en termes techniques mais flous comme "ajouter une fonction"), vous n'ajoutez pas grand chose à ce que Git stocke déjà dans le commit. Imaginez que vous lisiez le message de commit quelque temps plus tard ; quel type de résumé vous aiderait le plus à vous souvenir / à communiquer aux autres développeurs l'essence de ce changement ! Le contenu exact dépend de votre projet et de vos processus, mais je trouve que c'est une bonne ligne directrice.

Par conséquent, il faut avant tout ajouter le contexte (le pourquoi et non le comment ) avec votre message de commit (par exemple "frobnize the message to enable persistence") au lieu de "added frob() function"). C'est plus d'effort (vous devez réfléchir et pensez à ), mais il vaut tellement plus.

Si vous souhaitez en savoir plus sur ce sujet, il existe une mine d'informations, par exemple cet article du blog de Peter Hutterer o cette diapositive amusante .

Answer 2

Le modèle 50/72 semble être une bonne pratique, c'est-à-dire que la première ligne doit avoir une longueur maximale de 50 caractères et doit servir d'en-tête. Suivie d'un espace, la deuxième série de lignes doit comporter 72 caractères et doit servir de résumé. Voici une question sur l'OS : Messages de commit Git : formatage 50/72 qui discute de la même chose.

Voici quelques notes exhaustives sur le sujet :

1. GIT Commit Good Practice
2. Une note à propos des messages Git Commit
3. Des messages de commit Git appropriés et une histoire Git élégante

Answer 3

Git sait déjà quels fichiers vous avez modifiés dans un commit, il est inutile de le préciser dans le commentaire. Dites simplement par exemple "corrigé le bug du padding" ou "ajouté le menu dans la barre latérale". Soyez clair, c'est tout.