Standard à suivre lors de l'écriture des messages git commit
Je me retrouve à gérer de très nombreux fichiers (plus de 60 mais moins de 70) et mes messages de validation suivent ce schéma: lorsque j'ai ajouté quelque chose comme sur layout.css, mon message de validation est "quelque chose a été ajouté au fichier layout.css", et lorsque je supprime quelque chose, mon message de validation est "quelque chose a été supprimé du fichier layout.css" .
Certains fichiers sur la ligne, je regarde mon flux de validations et les messages ajoutés ... et supprimés ... dominent. Parfois, je ne me souviens pas de ce que j'ai supprimé ou de ce que j'ai ajouté dans layout.css puisque je fais tant de changements en même temps et que je me démène pour trouver un message de validation approprié.
Existe-t-il une norme à suivre pour m'aider à formuler mes messages de validation?
Lorsque vous décrivez simplement ce que vous avez fait (en termes techniques mais flous comme "ajouté une fonction"), vous n'ajoutez pas grand chose à ce que Git stocke déjà dans le commit. Imaginez-vous en train de lire le message de commit quelque temps plus tard; Quel genre de résumé vous aiderait le plus à se souvenir/communiquer à d’autres développeurs l’essence de ce changement?! Le contenu exact dépend de votre projet et de vos processus, mais j'estime que c'est un bon guide.
Par conséquent, avant tout, ajoutez un contexte (le pourquoi , pas le comment ) avec votre message de validation (par exemple "frobnize le message pour activer la persistance") au lieu de "added frob () function"). C'est plus d'effort (vous devez réfléchir et penser ), mais cela vaut tellement plus.
Si vous souhaitez en savoir plus sur ce sujet, vous trouverez une mine d'informations, par exemple cet article de Peter Hutterer ou cette diapositive amusante .
Le modèle 50/72 semble être une bonne pratique. c'est-à-dire ... la première ligne devrait avoir une longueur maximale de 50 caractères et devrait servir d'en-tête au serveur. Suivi d'un espace, le deuxième ensemble de lignes doit être enveloppé à 72 caractères et servir de résumé. Voici une SO question: Messages de validation Git: formatage 50/72) , qui traite de la même chose.
Voici quelques notes exhaustives sur le sujet:
Git sait déjà quels fichiers vous avez modifiés dans un commit, il est inutile de le spécifier dans le commentaire. Dites simplement par exemple "bug de remplissage corrigé" ou "menu ajouté dans la barre latérale". Faites bien comprendre, c'est tout.