Les messages de commit doivent-ils être écrits au présent ou au passé? [fermé]

Alors, lequel pensez-vous être le meilleur et le plus intuitif?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Veuillez fournir vos justifications. Remarquez que je pose la question de votre point de vue général, ce qui signifie que vous ne devriez pas essayer d'associer cela à vos outils svn / cvs ou langages de programmation préférés, mais plutôt le considérer comme quelque chose qui devrait / peut être appliqué à tous les outils et langages de programmation.

Je pense à ces messages tels qu'ils apparaissent aux autres développeurs. Ils n'ont pas encore appliqué les modifications, et il y a la question implicite, "que fera l'application de ce jeu de modifications / patch?" Cela "corrigera le bug XXX en YYY"!

Pour les autres verbes, les écrire sous forme de commande semble plus naturel et fonctionne mieux si vous avez un objectif spécifique à l'avance - vous pouvez littéralement écrire le résumé de la validation avec des tests préalables avant que le travail ne soit terminé.

Je n'y mets pas beaucoup de poids, mais pour moi, c'est la voie de la moindre résistance tout en maintenant la cohérence.

Personnellement, j'utilise le passé ("corrigé") car au moment où j'arrive à commettre le bogue est corrigé (ou je ne commettrais pas).

Je préfère voir les messages de validation au présent. De cette façon, le message décrit ce que fait le diff (car vous pouvez tirer ce diff ou même tout ce commit dans une branche différente). Ainsi, le message de validation ne décrit pas ce qu'il «a fait» faire ... Il décrit ce que le commit lui-même «fait» faire. Cela devrait donc être au présent.

Imaginez que vous regardez une différence de manière isolée et essayez de décider si vous allez l'appliquer. Cela n'a aucun sens d'avoir un titre au passé.

IMHO si vous voulez qu'il soit descriptif sans avoir besoin de considérer le contexte, alors "Fixed" est certainement la seule bonne variante.

En ce qui concerne l'intuitivité - si je regarde un journal des modifications, je comprendrai certainement que vous voulez dire le bogue corrigé car je connais le contexte dans lequel le mot est utilisé, mais mon cerveau le rattrapera beaucoup plus rapidement si le mot est écrit dans ce soi - spécifiant la manière.

"Fixing" est le pire choix à mon humble avis car il peut être interprété non seulement comme décrivant ce que fait le correctif (est pour) mais aussi comme un statut de bogue qui signifierait qu'il est en cours de traitement et n'est pas encore résolu.

Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

En général: {verbe impératif} l '{objet affecté} {qualificatifs facultatifs}

La forme impérative convient à tous les cas d'utilisation lorsque je considère un patchset.

• Que vas-tu faire ici?
• Que fait ce patchset?
• Pourquoi ce patchset a-t-il été créé? (pour corriger le bug xxx ...)
• Je dois corriger le bogue xxx dans yyy. Y a-t-il un commit sur une autre branche qui le fait déjà?

Quel que soit votre choix, je trouve que la cohérence contribue énormément à la lisibilité. Choisissez en un et gardez le.

Je pense qu'écrire sur le commit actuel au présent est une bonne idée, car cela rend les choses plus claires lorsque vous faites référence aux commits antérieurs au passé.

Je ne pense pas que cela compte vraiment. Le but est de:

1) Transmettez ce qui est fait ou ce qui était en cours, afin que les bogues puissent être trouvés plus facilement, les problèmes puissent être résolus plus facilement et généralement être en mesure de maintenir le projet plus facilement.

2) Indiquez quels tickets ont été corrigés, le cas échéant, afin que les auditeurs (s'ils sont utilisés dans votre entreprise puissent voir quels changements correspondent à quels tickets).

Enfin, s'il a déjà été corrigé, "Fixing" n'a pas de sens, et si vous travaillez toujours dessus, "Fixed" n'est pas correct.

" Fix bug X " est plus court de 2 caractères que " Fixed bug X ".
Et 3 plus courts que " Fixing bug X ".

Du point de vue de l'écriture de messages de commit courts, le présent sauve parfois / habituellement quelques caractères?
Ce qui, à mon avis, importe un peu, par exemple avec la recommandation de Git de moins de 50 caractères sur la première ligne de message de validation.
Aussi, moins de texte -> avez-vous fini de lire plus vite?

Un message de validation décrit pourquoi vous avez écrit le code en cours de validation.

«Problème résolu 3124» ou «Problème résolu 3124» semble correct car il indique que ce code corrige le problème 3124.

Cependant, la grammaire peut également dépendre de la raison pour laquelle le bogue est corrigé. Si vous pouvez marquer le bogue comme corrigé après la validation, alors "Corrigé" est très bien, mais si le bogue va être marqué comme corrigé par quelqu'un d'autre après avoir vérifié votre code, alors "Corrections" peut être plus approprié.

Je pense que la réponse la plus importante à une telle question est la suivante: tout le monde devrait utiliser ce qui fonctionne pour un projet spécifique et le garder au moins un tout petit peu cohérent.

Bien que je vois les avantages d'utiliser le présent (et que je suis en fait tombé sur ce post parce que j'ai vu des messages au présent dans des projets open source), je n'utiliserai probablement jamais le présent pour mes projets. C'est la méthode recommandée pour Linux et Git, et probablement d'autres projets open source plus importants, mais honnêtement, je m'en fiche tant que je ne fais pas partie de ces projets.

Je suis un développeur indépendant et j'utilise la première ligne d'un message de validation pour les notes de publication tandis que la description dans les lignes suivantes me donne une idée des détails de l'implémentation. C'est un flux de travail centré sur l'utilisateur par rapport à l'approche actuelle basée sur les développeurs. Je peux gagner du temps de cette façon. Il serait extrêmement artificiel de donner des instructions à mes utilisateurs dans les notes de publication. C'est mon travail de corriger les bugs et d'ajouter des fonctionnalités. Je dois gagner du temps, car je suis un indépendant. Je n'ai pas de «rédacteur de notes de publication» dans mon équipe.

Utilisez les règles d'un projet si elles sont déjà établies, mais restez pragmatique et faites tout ce qui facilitera ou accélérera votre travail.

Je pense que "Fixes XXX bug"cela a plus de sens que "Fix XXX bug"si la raison d'utiliser le présent est de "rendre plus descriptif ce que fait le commit" plutôt que ce que le committer a fait.

Si c'est un petit commit, j'utilise présent continu:

Correction du bug 304

ou

Ajout de commentaires

S'il s'agit d'un gros commit, je fais plus d'un journal des modifications:

• Corrige les bogues 453, 657 et 324
• Ajout de la syntaxe d'expression
• Refactorisation de la classe Operator.