Réponses:
j'utilise
[Abc]: Message.
Avec Add, Mod (ify), Ref (actoring), Fix, Rem (ove) et Rea (dability), il est facile d'extraire le fichier journal.
Exemple :
Add: New function to rule the world.
Mod: Add women factor in Domination.ruleTheWorld().
Ref: Extract empathy stuff to an abstract class.
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.
Rem: freeSpeech is not used anymore.
Rea: Removed old TODO and extra space in header.
Si j'ai plus d'une ligne, je les trie par ordre de priorité.
Modet Ref? Parfois, je ne fais que de petites corrections qui sont une sorte de refactoring.
Modconsiste à ajouter quelque chose ou à modifier un comportement, Refà modifier des éléments internes qui n’ajoutent aucune fonctionnalité, n’ajoutent pas d’API, etc. Exemple: si j’ai une add(Object)fonction et j’implémente une add(List<Object>)fonction, je vais commenter Mod. Plus tard , je supprimer les doubles emplois et d' utiliser directement add(Object)dans add(List<Object>)je vais utiliser Ref.
Nous utilisons les éléments suivants:
[Identifiant du ticket dans JIRA]: [Message: Qu'est-ce qui a été fait] Par exemple - ABC-123: Possibilité supplémentaire de configurer la présentation par région.
Dans ce cas, avec une intégration correcte, vous pourrez obtenir des fichiers modifiés / supprimés / ajoutés dans votre suivi des problèmes. Cependant, sachez que vous devez éviter quelque chose comme ABC-123: Terminé ou ABC-123: Corrigé avec des filtres si possible.
Il existe une règle simple, qui est une convention suivie par plusieurs (sinon tous) GDS et par la plupart des outils qui fonctionnent avec les GDS:
La première ligne d'un message de validation est un court résumé, tandis que le reste du message contient les détails.
Ainsi, la plupart des outils affichent uniquement la première ligne et affichent l'intégralité du message à la demande.
Une mauvaise utilisation typique d'un message de validation est une liste de modifications (seule la première puce sera affichée). Une autre utilisation abusive consiste à écrire un message détaillé sur une seule ligne.
Donc, s’il ya une chose à appliquer, je dirais que c’est la longueur maximale de la première ligne.
Personnellement, je n'ai jamais vu de modèle de commit général à utiliser. Le commentaire doit indiquer de manière concise ce que les commits sont liés, par exemple, quelle fonctionnalité / correction de bogue ou une brève déclaration expliquant pourquoi des modifications ont été apportées.
Les informations sur ce qui a été commis ne doivent pas être incluses, cela peut être déterminé par le système scm. Plus d'informations sur les bogues / fonctionnalités appartiennent aux endroits où les bogues et les fonctionnalités sont suivis.
Lors de la mise à jour d'un rapport de bogue après une validation, je trouve bon d'indiquer également la révision de validation avec les commentaires dans le rapport de bogue. De cette façon, vous pouvez trouver votre chemin entre le commentaire de validation et le rapport de bogue, et pour chaque commentaire du rapport de bogue, vous pouvez trouver ce qui a été commis, mais vous ne dupliquez pas les informations en les affichant à la fois dans le rapport de bogue et dans le message de validation.
Ensuite, lors de la visualisation de l'historique des révisions pour un fichier, vous avez de beaux messages brefs décrivant l'historique, mais vous savez également où chercher davantage de détails. Rapports de bogues ou descriptions de tâches pour plus de détails.
Dans Git, il est possible de faire presque n'importe quoi avec des hooks Git . Consultez les exemples dans .git / hooks pour des idées.
En ce qui concerne le message, dans un cas très général, vous souhaitez inclure suffisamment d'informations sur le problème que vous êtes en train de résoudre ET la solution elle-même pour pouvoir rechercher et identifier ce commit ultérieurement. Dans la plupart des cas, le problème sera référencé par un numéro de bogue (avec une intégration appropriée avec votre système de suivi des bogues). Si vous avez d'autres systèmes dans lesquels votre processus s'intègre (comme le système de suivi de révision de code), incluez également les bits appropriés:
Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.
BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none
MAIS vous voulez rester simple. Sinon, les gens trouveront un moyen de tromper le système et de produire des messages de validation inutiles.
Nous utilisons un template contenant
Les deux premiers sont omis la plupart du temps cependant (parfois les trois), donc ce n'est pas vraiment grave.
J'ai généralement l'identifiant qui se trouve dans le système de suivi des tickets que j'utilise ou une vue d'ensemble de haut niveau en première ligne. Ensuite, j'ai les éléments "bullet" de l'élément de campagne du changement spécifique dans le commit. Donc, je pourrais faire quelque chose comme:
MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity
C'est le format de validation le plus propre que j'aime. C'est direct et au point. Une autre raison pour laquelle je le fais de cette façon est que si je veux créer un journal des modifications, je peux simplement prendre tous les messages de validation et les analyser dans un journal des modifications très facilement.
[ticketId] [ABC] [topicId] [WIP] Message, où:
Exemples:
[# 452567] [add] [menu_it] nouvel élément - livre d'or
[# 452363] [correction] [banner_top] [WIP] 1024x300 peut être utilisé maintenant
[# 452363] [fix] [bannière_top] 500x200 peut être utilisé maintenant
[ # 452713] [rem] [page] annonce au milieu à gauche