Réponses:
Les outils de contrôle de version sont suffisamment puissants pour permettre à la personne de voir quels fichiers ont été modifiés et quelles méthodes ont été ajoutées. Cela signifie qu'en général, les messages de journal qui dupliquent clairement ce qui existe déjà polluent le journal.
Vous avez ajouté une somefuncméthode pour remplir une exigence, à savoir:
Cela signifie que vos messages de journal doivent plutôt expliquer quelles fonctionnalités / quels bugs ont été affectés ou quel était l'objectif du refactoring.
N'oubliez pas d'ajouter TICKET / NUMÉRO D'ÉDITION .
Si vous avez une fonctionnalité ou un système de suivi de problème avec un numéro de ticket ou un numéro de problème , assurez-vous de mettre ce numéro d’identification dans la validation. Cela aidera tous ceux qui souhaitent en savoir plus sur la fonctionnalité ou le problème sur lequel vous travailliez.
Dans mon dernier projet, une macro avait été mise au point pour s’assurer que les 7 premiers chiffres du commentaire étaient un numéro correct issu d’une quête claire (notre système de suivi des problèmes / fonctionnalités).
Je fais ce genre de chose lorsque je commets, par exemple, le correctif pour un défaut nécessitant des modifications de plusieurs fichiers. Cela rend un peu plus facile de dire ce qui a réellement changé sans regarder les fichiers individuels dans le changeset.
Cela n'est pas nécessaire pour les modifications d'un seul fichier.
La première ligne est toujours une description de haut niveau du changeset, par exemple un lien vers le défaut ou la user story.
S'il s'agit d'informations pertinentes dans le récit du message de validation, alors oui, incluez-les. Si la seule information est le nom du fichier lui-même, alors non.
Par exemple, cela a du sens: "Déplacé la fonction build_foo () de fooutil.c à foobase.c, car la plupart des programmes qui souhaitent utiliser build_foo () incluent déjà foobase.c"
Celui-ci ne: "Mis à jour le build_foo () dans fooutil.c pour prendre un paramètre de barre."
Je veux ajouter une perspective différente ici.
Ma réponse est oui ou non, mais en général je dirais oui.
Le contrôle de version est en effet assez puissant pour savoir quel fichier est mis à jour. Mais quand on fait
$ git log
Nous ne voyons que le message commit. C'est ce que font la plupart des gens.
En regardant dans le journal lui-même. Cela ajoute un contexte supplémentaire. Par exemple:
readme.md: Fix typo detected by language tool
Est mieux que
Fix typo detected by language tool
Toutefois, si les modifications génèrent plusieurs fichiers, mentionnez au moins le composant en cours de modification.
API: Fix reset password not sent email to user
En le lisant, nous savons que l'erreur corrigée se produit au niveau du composant API et probablement dans le répertoire API au niveau de la base de code.
Nous pourrions cependant faire
$ git show COMMIT_ID --name-only
mais cela ajoute plus d’étape juste pour récupérer les fichiers.
La seule fois où j'ai pu constater que cela était utile pour l'archivage d'un fichier unique, c'est si vous avez modifié une fonction utilisée à de nombreux endroits dans le fichier, ce qui a pour résultat que le fichier diff est encombré. Même alors, je mettrais en premier le numéro de suivi des modifications et une description en texte clair des modifications.
Je pense que la vraie question est de savoir quelle est la portée de vos commits. Si vous attendez la validation de diverses modifications non liées dans une validation, vous pourriez alors ressentir le besoin de spécifier quels fichiers ont été modifiés et dans quel but.
Toutefois, si vous faites simplement des commits plus étroits plus fréquemment, un seul commet vous expliquera quels fichiers ont été modifiés et vous pouvez simplement décrire l'objectif de ce message.
Plus commet, plus souvent. C'est la façon dont vous pouvez éviter d'être aussi prolixe dans vos messages.