git tag




Devrais-je utiliser le passé ou le présent dans les messages de commit git? (5)

J'ai lu une fois que les messages de commit git devraient être au présent impératif, par exemple "Ajouter des tests pour x". Je me retrouve toujours à utiliser le passé, par exemple "Ajout de tests pour x", ce qui me semble beaucoup plus naturel.

Voici un commit récent de John Resig montrant les deux en un message:

Tweak un peu plus de résultats set jQuery dans les tests de manipulation. Également fixé l'ordre des résultats de test attendus.

Est-ce que ça importe? Lequel dois-je utiliser?


C'est à toi de decider. Utilisez simplement le message de validation comme vous le souhaitez. Mais c'est plus facile si vous ne passez pas d'une langue à l'autre.

Et si vous développez dans une équipe - il devrait être discuté et fixé fixe.


Est-ce que ça importe? les gens sont généralement assez intelligents pour interpréter correctement les messages, s'ils ne le sont pas, vous ne devriez probablement pas les laisser accéder à votre dépôt de toute façon!


La préférence pour les messages de commit de style impératif au présent provient de Git lui-même. De Documentation/SubmittingPatches dans le repo Git:

Décrivez vos changements d'humeur impérative, par exemple "make xyzzy do frotz" au lieu de "[Ce patch] fait xyzzy do frotz" ou "[I] a changé xyzzy en frotz", comme si vous donniez des ordres au code pour modifier son comportement.

Ainsi, vous verrez beaucoup de messages de commit Git écrits dans ce style. Si vous travaillez sur une équipe ou sur un logiciel open source, il est utile que tout le monde adhère à ce style pour la cohérence. Même si vous travaillez sur un projet privé, et que vous êtes le seul à avoir jamais vu votre histoire de git, il est utile d'utiliser l'esprit impératif car il établit de bonnes habitudes qui seront appréciées lorsque vous travaillerez avec d'autres personnes.


Pour qui écrivez-vous le message? Et ce lecteur lit-il généralement le message avant ou après la prise de possession?

Je pense que les deux points de vue ont donné de bonnes réponses, mais je ne dirais peut-être pas qu'il y a une meilleure réponse pour chaque projet. Le vote par division pourrait suggérer autant.

c'est-à-dire pour résumer:

  • Est-ce que le message prédomine pour les autres personnes, généralement en train de lire à un moment donné avant d'avoir assumé le changement: Une proposition de ce que le changement apportera à leur code existant.

  • Est-ce que le message est principalement un journal / un dossier pour vous-même (ou pour votre équipe), mais généralement en lisant du point de vue d'avoir assumé le changement et en cherchant à découvrir ce qui s'est passé.

Peut-être que cela va conduire la motivation de votre équipe / projet, de toute façon.


Votre projet devrait presque toujours utiliser le passé . Dans tous les cas, le projet doit toujours utiliser le même temps pour la cohérence et la clarté.

Je comprends certains des autres arguments qui prétendent utiliser le présent, mais ils ne s'appliquent généralement pas. Les points suivants sont des arguments communs pour écrire au présent, et ma réponse.

  • Écrire au présent dit à quelqu'un ce que fera l'engagement , plutôt que ce que vous avez fait.

C'est la raison la plus juste pour laquelle on voudrait utiliser le présent, mais seulement avec le bon style de projet. Cette manière de penser considère tous les commits comme des améliorations ou des caractéristiques optionnelles, et vous êtes libre de décider quels commits conserver et lesquels rejeter dans votre référentiel particulier.

Cet argument fonctionne si vous avez affaire à un projet réellement distribué. Si vous traitez un projet distribué, vous travaillez probablement sur un projet open source. Et c'est probablement un très gros projet s'il est vraiment distribué. En fait, c'est probablement le noyau Linux ou Git. Puisque Linux est probablement ce qui a fait que Git a gagné en popularité, il est facile de comprendre pourquoi les gens considèrent son style comme l'autorité. Oui, le style a du sens avec ces deux projets. Ou, en général, cela fonctionne avec de grands projets distribués open source .

Cela étant dit, la plupart des projets dans le contrôle de la source ne fonctionnent pas comme ça. Il est généralement incorrect pour la plupart des dépôts. C'est une façon moderne de penser à un commit: les dépôts Subversion (SVN) et CVS pourraient à peine supporter ce type de check-in de référentiel. Habituellement, une branche d'intégration gérait les mauvais enregistrements, mais ceux-ci n'étaient généralement pas considérés comme des fonctionnalités «optionnelles» ou «sympa».

Dans la plupart des scénarios, lorsque vous effectuez des validations dans un référentiel source, vous rédigez une entrée de journal qui décrit les modifications apportées à cette mise à jour, afin de permettre aux autres utilisateurs de comprendre les raisons de cette modification. Il ne s'agit généralement pas d'un changement optionnel - les autres personnes du projet doivent soit fusionner soit rebaser. Vous n'écrivez pas d'entrée dans un journal comme "Cher journal, aujourd'hui je rencontre un garçon et il me dit bonjour", mais à la place tu écris "J'ai rencontré un garçon et il m'a dit bonjour".

Enfin, pour de tels projets non distribués, 99,99% du temps qu'une personne lira un message de commit est pour lire l'histoire - l'histoire est lue au passé. 0,01% du temps, il décidera s'ils doivent ou non appliquer cette validation ou l'intégrer dans leur branche / référentiel.

  • Cohérence. C'est comme ça dans de nombreux projets (y compris git lui-même). De même, les outils git qui génèrent des commits (comme git merge ou git revert) le font.

Non, je vous garantis que la majorité des projets déjà connectés dans un système de contrôle de version ont eu leur histoire au passé (je n'ai pas de références, mais c'est probablement juste, vu que le présent argument est nouveau depuis Git). Les messages de "révision" ou les messages de validation au présent ne commencent à prendre sens que dans des projets réellement distribués - voir le premier point ci-dessus.

  • Les gens lisent non seulement l'histoire pour savoir «ce qui est arrivé à cette base de code», mais aussi pour répondre à des questions telles que «Que se passe-t-il lorsque je choisis ce commit» ou «Quel genre de nouvelles choses vont arriver à mon code? Je peux ou ne peux pas fusionner dans le futur ".

Voir le premier point. 99,99% du temps qu'une personne lira un message de commit est pour lire l'histoire - l'histoire est lue au passé. 0,01% du temps, il décidera s'ils doivent ou non appliquer cette validation ou l'intégrer dans leur branche / référentiel. 99,99% bat 0,01%.

  • C'est généralement plus court

Je n'ai jamais vu un bon argument qui dit utiliser un temps / une grammaire impropre parce que c'est plus court. Vous ne sauvegarderez probablement que 3 caractères en moyenne pour un message standard de 50 caractères. Cela étant dit, le temps présent en moyenne sera probablement plus court de quelques caractères.

  • Vous pouvez nommer les commits de manière plus cohérente avec les titres des tickets dans votre numéro de suivi / fonctionnalité (qui n'utilisent pas le passé, bien que parfois futur)

Les billets sont écrits soit comme quelque chose qui se passe actuellement (par exemple, l'application montre un mauvais comportement lorsque je clique sur ce bouton), ou quelque chose qui doit être fait dans le futur (par exemple le texte devra être révisé par l'éditeur).

L'histoire (c'est-à-dire les messages de commit) est écrite comme quelque chose qui a été fait dans le passé (par exemple, le problème a été résolu).







commit-message