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

102

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.

version-control coding-style

— Her
source

Quelqu'un à votre travail est trop pédant, j'espère que ce n'est pas vous. Celui qui il s'agit devrait considérer le présent parfait contre le présent imparfait, et l'énigme philosophique de savoir si le commentaire de commit est lu comme s'il était du moment où il a été tapé, ou du moment où il était lui-même persisté jusqu'au référentiel. Dans ce dernier cas, utilisez present perfect pour une action terminée. Si le premier, utilisez imparfait pour une activité actuelle incomplète.

— Heath Hunnicutt

1

Pas une dupe de cette question. Cela concerne un petit aspect et non des directives générales.

3

Heureusement, ce n'est pas le cas. Je demandais, en essayant de le savoir, je voudrais savoir quelle est la pratique générale là-bas. Si je dois vous dire la vérité, c'est en fait la question la plus insignifiante que j'ai jamais posée sur SO, mais bon, c'est toujours une question, n'est-ce pas? La question elle-même a remporté trois votes, ce qui (sinon évident pour vous) indique que je ne suis pas le seul à penser que cette question est valable en soi. Je recherche des réponses constructives et vous ne m'avez pas du tout utile.

— Son

1

Si vous pensiez que les gens ne devraient pas trop s'inquiéter des temps dans les messages de commit, dites-le, indiquez vos raisons et vos préférences. Beaucoup plus utile et utile que votre commentaire sarcastique ci-dessus.

— Son

10

Je prends cette question très au sérieux. C'est une excellente question. Être cohérent est très important lors du développement de logiciels, et cela devrait intéresser tous les visiteurs intéressés par le sujet de ce site Web. C'est mon avis.

— Niklas Berglund

39

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.

— Roger Pate
source

8

Je me souviens avoir rencontré quelque chose dans la documentation git recommandant fortement ce temps, mais je trouve toujours dans maladroit.

— keithjgrant

1

C'est la partie de la documentation de Git qui provient.

— sschuberth le

31

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

— cletus
source

Pouvez-vous en donner un exemple?

— bzlm

15

un exemple de cela.

— Révérend Gonzo

Cela s'appelle «Commit History». L'histoire est toujours écrite au passé. Le passé a donc plus de sens. Lorsque vous parcourez également l'historique des validations d'un repo, vous regardez ce qui a été fait ... dans le passé!

— Shiva

13

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é.

— TedPavlic
source

1

"ce que fait le diff" mais le diff est créé par un commit qui a été commité , il est déjà dans l'historique de git, donc il était déjà "appliqué".

— Iulian Onofrei

9

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.

— Ivan
source

7

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.

— phord
source

4

De très bonnes raisons. Je considère toujours cela comme si le message disait "Je suis un patch et je [message]". De cette façon, vous commencez toujours par un verbe impératif.

— florisla du

5

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é.

— Ken Bloom
source

1

Je suis d'accord. Si le commit se réfère à lui-même, il est également vrai, comme dans "Ce commit corrige le bogue F00F".

— bzlm

4

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.

— Révérend Gonzo
source

1

Bien sûr, à proprement parler, il est vrai que cela n'a pas vraiment d'importance. Mais si vous devez en choisir un, lorsque vous avez corrigé un bogue dans votre arborescence locale et que vous souhaitez valider les modifications apportées, dites-vous "Fixed XXX" ou "Fixes XXX" ou "Fix XXX"?

— Son

1

Je pense qu'il importe que le texte soit trop bref. Parfois, je vois des messages de validation qui me font me demander si 1. un bogue a été trouvé ou réellement corrigé, ou 2. si un correctif a été conçu ou réellement appliqué, ou 3. si un comportement erroné complexe a été partiellement ou en fait entièrement corrigé. Et parfois, plusieurs commits concernent le même bogue. Dans "Ce commit corrige le problème de rebond dans DrawBall () et ferme le ticket 666", le temps n'a pas d'importance, car le texte est verbeux. Mais pour "DrawBall () rebondit mal", qu'a fait le commit?

— bzlm

2

" 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?

— KajMagnus
source

1

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é.

— Parag
source

0

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.

— Rafael Bugajewski
source

-1

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.

— technophyle
source

-4

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.

— tster
source

9

en d'autres termes, vous les mélangez tous bon gré mal gré B-)

— Brian Postow

Plutôt. Parce qu'en fin de compte, les messages de validation n'ont pas besoin d'être les reines anglais.

— tster

2

De toute façon, vous ne devriez pas faire beaucoup de choses différentes en un seul commit.

— florisla