Les besoins pour cette question sont de
Aujourd'hui, nous utilisons des drapeaux dans les messages de validation tels que
En tant que tel, mon premier coup de poing à ce sujet serait d'ajouter un autre niveau à ces drapeaux, par exemple
Mais alors, comment approcheriez-vous la possibilité d'avoir commis des messages écrits pour les changelogs (c'est-à-dire trop élevé); ou plusieurs messages concernant le même problème de Changelog. Peut-être que les messages Changelog devraient plutôt être extraits lorsque des branches de fonctionnalités sont fusionnées? Existe-t-il des fonctionnalités de SCM: S (par exemple Git) qui gère ce problème pour vous?
Mettez simplement: existe une stratégie standard de l'industrie, ou un outil, pour extraire des messages de validation utiles dans des changelogs avec facilité? Ajouter | REF | REM | Correction: cl-ajout: fonction x (cl = changelog) puis analyser tous les messages de validation pour ^ cl- (Ajouter | REF | REM | Correction> Pour ajouter à le changelog.
3 Réponses :
Je ne connais aucun outil standard, mais comme vous n'avez pas reçu de réponse pendant un moment, voici quelques idées:
Alors d'abord, essayez d'éviter un fichier de changelog, comme vous le suggérez, c'est probablement une bonne idée en général en raison de tous les conflits de fusion qu'un tel fichier a tendance à causer. (Sauf si vous avez un outil de fusion automatique intelligent.)
Quelque chose comme un cl: ou un journal: préfixe pour une extraction facile est probablement une bonne idée. En ce qui concerne Add / Ref / Rem / Correction: (Je suppose que Mais alors, comment approcheriez-vous la possibilité d'avoir commis des messages écrits juste pour les changelogs (c'est-à-dire un niveau trop élevé);
Je dirais, mettez le ( ou plusieurs messages concernant le même problème de Changelog.
Nous parlons de quelque chose comme ça, non?
Et c'est là que je pense que la chose "Changelog automatique" devient délicate. Sauf si vous êtes prêt à rebaser et à éditer des messages commettez des messages après le fait (comme supprimer «CL:» de COMMIT (1) ci-dessus), je suggère que le seul moyen pratique d'y aller, chaque fois que vous faites une libération. , pour extraire tous les paragraphes marqués du journal Git depuis votre dernière version et modifier manuellement la liste résultante, fusionner des éléments tels que (1) et (2) ci-dessus, et se tournant, disent, "fixe # 145", "fixe # 153 "," Fixe # 164 "en une seule ligne" fixe # 145, # 153 et # 164. "
espoir que j'ai pu fournir une certaine inspiration. Faites-nous savoir ce que vous finissez par faire! ref et REM stand pour "refacteur" et "supprimer", non?) Quand vous écrivez un changeelog Je préfère rester avec des entrées de forme libre. Par exemple, je ne suis pas sûr que les refactorings appartiennent à un changelog et que les fonctionnalités sont suffisamment de haut niveau pour justifier des entrées Changelog N'EST généralement pas supprimées. Ils sont plutôt changés en une autre forme.
cl: -tagged) Description de haut niveau dans un paragraphe du message de validation et la description technique de niveau inférieure dans un autre paragraphe.
Oui, je commence à comprendre que "automatique" devrait faire référence à la liste des bons engagements pour choisir des engagements essentiels à partir de, plutôt que de les sélectionner uniquement sur l'intention actuelle d'un commit (comme lorsque "Bogue fixe # 124" ne doit pas Vraiment corriger le bogue n ° 124, mais un engagement ultérieur corrige effectivement ce bug). Merci!
J'ai essayé cela moi-même avec peu de chance dans le passé. Fondamentalement, il est en fait plus travail à faire penser à chaque développeur, pour chaque commit, sur le point de savoir si leur message de validation est trop effrayant pour les clients ou non. Les développeurs ne sont généralement pas la bonne personne à prendre cette décision et de le faire un peu à la fois est inefficace.
Après beaucoup d'expérimentation, ce qui a fonctionné pour moi est trivial: juste avant chaque sortie, une personne passe par le journal Git depuis la dernière version et écrivez toutes les choses intéressantes dans un fichier de changelog. Ce n'est vraiment pas plus de travail que l'autre sens; La plupart des travaux sont décidés, ne formulent pas de formuler. Et le processus de décision nécessite un état d'esprit particulier, il est donc plus efficace d'avoir une personne le faire dans un grand lot que d'un groupe de développeurs faisant un petit peu à la fois. (Pensez-y de cette façon: vous n'avez pas à continuer à échanger la partie «Vérification du client de commit le message» du travail dans la cache.)
Si vous voulez vraiment marquer des messages commettez des messages avec ce type d'informations, vous devez au moins envisager de le faire avec git notes au lieu du message de validation brut. Ensuite, si quelqu'un le vise en marquant le contraignant de manière incorrecte comme bug / fonctionnalité / etc., vous pouvez le réparer en mettant à jour l'annotation.
Cela ressemble à une solution acceptable, mais j'ai besoin de clarification. Comment travaillez-vous avec Annotate (ou blâme ), et pourquoi est-ce plus utile que quelque chose comme git commit -amend ? Est-ce parce que c'est sur un autre niveau de priorité ou quelque chose? (De bonnes références aideraient :)) L'approche serait alors "Obtenir tous les messages" (Soyez-lui des messages du type précédemment indiqué) "depuis la balise précédente et les afficher dans une liste agréable".
Désolé, je ne sais pas pourquoi j'ai dit "Git Annotate". "Notes Git" est ce que je voulais dire; J'ai édité la réponse.
Très bien, je ne savais pas sur git notes jusqu'à présent. Avez-vous une bonne référence à parcourir le journal Diff-by-DIFF ou quoi que ce soit plus intelligent, avant d'appliquer les notes? Vous donner les points pendant ce temps!
Voulez-vous juste "git bûche -p" ou quelque chose de plus spécifique?
Avez-vous pensé à utiliser un crochet de pré-validation qui met à jour le changeelog avant le commit?
@ Dave1010: La question est plus visant à définir les messages qui devraient aller dans le changelog, et non comment le mettre à jour. J'ai essayé de reformater la question, merci pour un commentaire valide cependant! (Et je conviens qu'un crochet pourrait le faire, post-commister cependant; ou dans le cadre du script de construction / déploiement.)