Un message git commit doit-il mentionner le fichier qui a été modifié?
Dans la première ligne d'un message git commit, j'ai l'habitude de mentionner le fichier qui a été modifié si un changement ne couvre pas plusieurs fichiers, par exemple:
Add [somefunc] to [somefile]
Est-ce une bonne chose à faire ou est-ce inutile?
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é la méthode somefunc pour répondre à une exigence, à savoir:
- pour ajouter une fonctionnalité,
- pour supprimer un bug ou
- pour refactoriser le code source.
Cela signifie que vos messages de log doivent plutôt expliquer quelles fonctionnalités/bugs ont été affectés ou quel était le but du refactoring.
Non. Il existe de nombreuses façons d'examiner le conten d'un commit. Le commentaire doit décrire le objectif du commit.
N'oubliez pas d'ajouter BILLET/NUMÉRO D'ÉMISSION.
Si vous avez une fonctionnalité ou un système de suivi des problèmes avec un ticket # ou issue #, assurez-vous de mettre cet ID # dans la validation. Cela aidera toute personne souhaitant en savoir plus sur la fonctionnalité ou le problème sur lequel vous travailliez.
Dans mon dernier projet, il y avait une macro qui a été développée pour s'assurer que les 7 premiers chiffres du commentaire étaient un numéro de problème valide de la recherche claire (notre système de suivi des problèmes/fonctionnalités).
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 suffisamment puissant pour savoir quel fichier est mis à jour. Mais quand nous le faisons
$ git log
Nous ne voyons que le message de validation. C'est ce que font la plupart des gens.
En consultant le journal lui-même. Il y ajoute un contexte supplémentaire. Par exemple:
readme.md: Fix typo detected by language tool
Est mieux que
Fix typo detected by language tool
Cependant, 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 en cours de correction est au niveau du composant API, et probablement sous le répertoire API à la base de code.
On pourrait cependant faire
$ git show COMMIT_ID --name-only
mais cela ajoute plus d'étape juste pour obtenir les fichiers.
Je fais ce genre de chose quand je m'engage, par ex. le correctif d'un défaut qui nécessitait des modifications dans plusieurs fichiers. Cela rend un peu plus facile de dire ce qui a réellement changé sans regarder les fichiers individuels dans le changeset.
Pour les ensembles de modifications à fichier unique, cela n'est pas nécessaire.
La première ligne est toujours une description de haut niveau de l'ensemble de modifications, comme 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 le seul élément d'information est le nom du fichier lui-même, alors non.
Par exemple, cela a du sens: "Déplacement de la fonction build_foo () de fooutil.c vers foobase.c, car la plupart des programmes qui souhaitent utiliser build_foo () incluent déjà foobase.c"
Celui-ci ne fait pas: "Mise à jour de build_foo () dans fooutil.c pour prendre un paramètre de barre."
Si vous pouvez inclure le verbe dont le fichier est représentatif, par exemple slideDesigner: fixed funcX(), returns obj au lieu du nom de fichier réel (par exemple slide-designer.vue Ou main-slide-designer), C'est beaucoup mieux.
En fin de compte, il n'y a pas de règle stricte/rapide que vous devez suivre, cela se résume à ce que vous êtes à l'aise et en confiance. À mon humble avis, si j'inclus le terme slideDesigner plutôt que simplement fixed funcX(), returns obj cela rend l'historique de validation plus utilisable pour moi et je suis plus susceptible de rechercher plus avant les fichiers réels dans ce commit car je sais avant d'un contexte (slideDesigner) pour que mon esprit soit en relation constructive avec le problème que je traite actuellement.
Merci.
Regardez à quel point il est facile ou difficile de déterminer quels fichiers un commit a modifiés et/ou à quel point il est facile de comprendre la liste des commits modifiant un fichier. Basez ensuite votre décision sur vos conclusions. Votre configuration peut être différente de la mienne.
(Par exemple, l'éditeur Xcode a un bouton "historique" qui montre deux versions côte à côte avec un diff, et vous pouvez choisir des validations pour chaque côté. Inutile d'avoir le fichier mentionné dans le message de validation. À moins que le changement ne soit quelque chose comme "Correction des commentaires obsolètes xyz.cpp".)
La seule fois où j'ai pu voir que cela était utile pour un enregistrement de fichier unique, c'est si vous avez apporté des modifications à une fonction utilisée à de nombreux endroits dans le fichier avec le résultat que le diff est encombré. Même alors, je mettrais d'abord le suivi des modifications # et une description en texte brut de la modification.