Votre projet doit 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 faisant valoir l'utilisation du présent, mais ils ne s'appliquent généralement pas. Les points suivants sont des arguments courants pour écrire au présent et ma réponse.
- Écrire au présent indique à quelqu'un ce que l'application du commit fera , plutôt que ce que vous avez fait.
C'est la raison la plus correcte pour utiliser le temps présent, mais uniquement avec le bon style de projet. Cette manière de penser considère toutes les validations comme des améliorations ou fonctionnalités facultatives, et vous êtes libre de décider quelles validations conserver et lesquelles rejeter dans votre référentiel particulier.
Cet argument fonctionne si vous avez affaire à un projet véritablement distribué. Si vous avez affaire à 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. Étant donné que Linux est probablement la cause de la propagation et de la popularité de Git, il est facile de comprendre pourquoi les gens considéreraient son style comme l'autorité. Oui, le style a du sens avec ces deux projets. Ou, en général, il fonctionne avec de grands projets distribués open source .
Cela étant dit, la plupart des projets de contrôle de code source ne fonctionnent pas comme ça. Il est généralement incorrect pour la plupart des référentiels. C'est une façon moderne de penser aux commits: les référentiels Subversion (SVN) et CVS pourraient à peine supporter ce style d'archivage de référentiel. Habituellement, une branche d'intégration traitait le filtrage des mauvais enregistrements, mais ceux-ci n'étaient généralement pas considérés comme «facultatifs» ou «fonctionnalités intéressantes».
Dans la plupart des scénarios, lorsque vous effectuez des validations dans un référentiel source, vous écrivez une entrée de journal qui décrit ce qui a changé avec cette mise à jour, pour permettre aux autres utilisateurs de comprendre pourquoi une modification a été effectuée. Ce n'est généralement pas un changement facultatif - d'autres personnes dans le projet doivent fusionner ou rebaser dessus. Vous n'écrivez pas un journal tel que "Cher journal, aujourd'hui je rencontre un garçon et il me dit bonjour.", Mais à la place vous écrivez "J'ai rencontré un garçon et il m'a dit bonjour".
Enfin, pour de tels projets non distribués, 99,99% du temps, une personne lira un message de validation pour lire l'historique - l'histoire est lue au passé. 0,01% du temps, il décidera s'ils doivent appliquer ce commit 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). Les outils git qui génèrent des commits (comme git merge ou git revert) le font également.
Non, je vous garantis que la majorité des projets jamais 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 vrai, étant donné que l'argument du temps présent est nouveau depuis Git). Les messages de «révision» ou de validation au présent n'ont commencé à avoir un sens que dans les projets vraiment distribués - voir le premier point ci-dessus.
- Les gens lisent non seulement l'historique pour savoir «ce qui est arrivé à cette base de code», mais aussi pour répondre à des questions comme «ce qui se passe quand je sélectionne ce commit», ou «quel genre de nouvelles choses vont arriver à ma base de code à cause de ces commits Je pourrai ou non fusionner à l'avenir ".
Voir le premier point. 99,99% du temps, une personne lira un message de validation pour lire l'historique - l'histoire est lue au passé. 0,01% du temps, il décidera s'ils doivent appliquer ce commit 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 mauvais temps / grammaire parce qu'il est plus court. Vous n'enregistrerez 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 de quelques caractères plus court.
- Vous pouvez nommer les validations de manière plus cohérente avec les titres des tickets dans votre tracker de problème / fonctionnalité (qui n'utilisent pas le passé, bien que parfois futur)
Les tickets sont écrits soit comme quelque chose qui se passe actuellement (par exemple, l'application affiche un mauvais comportement lorsque je clique sur ce bouton), soit comme quelque chose qui doit être fait à l'avenir (par exemple, le texte devra être révisé par l'éditeur).
L'historique (c'est-à-dire les messages de validation) est écrit comme quelque chose qui a été fait dans le passé (par exemple, le problème a été résolu).