Écrire des messages de commit en tant que développeur solo?

Sur mes projets où le référentiel est partagé entre moi et d'autres programmeurs, j'écris toujours des messages de commit même si je suis le développeur principal.

Mais sur les projets où je suis le développeur solo travaillant sur un projet, et le référentiel est hébergé sur mon ordinateur portable personnel, et n'est même pas hébergé par le client, donc personne sauf moi ne verrait les commits, si j'écrivais encore commit messages?

Jusqu'à présent, je les ai écrits, mais j'ai constaté que je ne suis jamais revenu en arrière et que j'ai vu mes messages de validation. Je prends du temps pour écrire les messages, mais ils ne sont plus jamais revus, même par moi.

Y a-t-il de bonnes raisons d'écrire des messages de validation en tant que développeur solo, ou devriez-vous simplement les ignorer en faveur de rester concentré sur le développement?

Eh bien, voici une raison: si vous réalisez soudainement que quelque chose a été cassé au cours des dernières centaines de validations (possible si vous vous engagez à chaque modification mineure, moins faisable si vous, comme moi, ne validez que des instantanés "stables"), vous pouvez plus facilement trouver où vous avez inséré le bogue si vous avez écrit des messages de validation clairs, plutôt que des «corrections de bogues». (La chaîne préférée d'un collègue, je crois). Bien sûr, vous pouvez aller avec svn logou n'importe quel SCM que vous utilisez, mais cela devrait être plus facile dans l'autre sens.

Les messages d'engagement vous obligent également à penser exactement ce que vous avez fait en tant que changement et, je crois, à résumer dans votre esprit la meilleure façon de continuer à améliorer le projet.

J'essaye de toujours. Combien de fois regardez-vous en arrière et pensez-vous: "Qu'est-ce que je faisais quand j'ai fait ce changement." Je fais tout le temps. 30 secondes d'écriture d'un message peuvent vous faire économiser 20 minutes de travail en essayant de vous souvenir.

Croyez-vous honnêtement que la surcharge de la frappe d'environ 40 à 80 caractères en anglais simple est une surcharge importante pour un commit, ou cherchez-vous une excuse pour être paresseux?

Peut-être que votre problème est d'exprimer en anglais simple pourquoi vous avez effectué le changement, auquel cas, vous devrez peut-être revoir le but du changement, même au point de vous demander si vous avez vraiment besoin de le faire.

Mon conseil est de ne pas penser que parce que vous volez en solo, vous pouvez enfreindre les règles. Restez professionnel à tout moment et ajoutez des messages de validation significatifs. Comme l'ont noté d'autres répondants, un jour vous en serez reconnaissant.

• Vous ne serez pas toujours un développeur solo.

• Vous allez éventuellement casser votre base de code et tenter de la restaurer. De bons messages de validation vous feront gagner des heures.

• Vous ne vous souvenez pas sur quoi vous travailliez il y a trois semaines, non?

• Les messages de validation doivent être très clairs. Si ce n'est pas le cas, vous n'avez pas terminé de travailler sur une tâche ou une seule tâche s'est répartie sur deux tâches ou plus.

Certainement, sinon vous rendez les fonctionnalités comme la ramification et la fusion beaucoup plus difficiles à utiliser. Et vous aurez envie de les utiliser, même si développeur solo.

Une raison possible: cela vous oblige à réfléchir de manière plus abstraite au changement que vous venez de faire et à structurer les changements.

Si cela vous semble inutile, commentez peut-être simplement les changements majeurs ou ceux qui modifient les fonctionnalités existantes, au cas où vous chercheriez la source d'un comportement étrange.

J'ai été le seul contributeur sur le projet TXR, et j'ai gardé un ChangeLog détaillé assez tôt dans le projet. Cela fait près de 11 000 lignes et continue de croître: http://www.kylheku.com/cgit/txr/tree/ChangeLog

(Les messages de validation dans le référentiel ne sont qu'une copie de ce qui se trouve dans le ChangeLog.)

[Édition 2016: depuis la mi-2015, je ne gère plus de fichier ChangeLog; cependant, les messages de validation sont écrits dans un format conforme aux conventions Git et ChangeLog en même temps. Le même niveau de détail est là, d'une manière qui ne cause pas de problèmes de fusion. Un fichier ChangeLog pourrait être reconstruit mécaniquement à partir de ces commentaires.]

Oui, plus d'une fois, je suis retourné à un ancien message de validation associé à un changement qui a cassé quelque chose (découvert avec l'aide de git bisect). Le message m'a aidé à comprendre ce que je faisais.

Dans le ChangeLog, vous pouvez savoir quand une fonction, un type, une macro ou une variable globale a été introduite pour la première fois et quand elle a ensuite été touchée par des modifications.

Mais la principale raison d'écrire des messages de validation détaillés comme ceux-ci lorsque vous travaillez par vous-même est la suivante: vous trouvez des bogues en faisant cela .

Écrire un message de validation détaillé présente des avantages similaires à un examen du code de votre validation par quelqu'un d'autre. La valeur d'un examen de validation n'est pas tant que quelqu'un vérifie votre code, mais que vous devez expliquer vos modifications à un autre développeur.

Lorsque vous essayez d'expliquer des choses, vous trouvez parfois qu'elles n'ont pas de sens.

Une autre raison: vous pouvez vous surprendre à faire un changement inutile . En écrivant un commentaire de validation détaillé, vous capturez une vue d'ensemble de ce que vous faites, puis vous êtes parfois confronté au fait que ce n'est pas un bon changement.

J'ai parfois fait des changements, quand au milieu de l'écriture de l'entrée ChangeLog j'ai réalisé que ça allait être un git reset --hard(jeter ces changements inutiles) plutôt que git commit -a.

Bien que vous n'ayez pas encore rencontré la nécessité de voir vos messages de validation, vous pourriez leur être très reconnaissant à l'avenir. Vous devriez continuer à les écrire même pour vous. Il existe de nombreuses raisons pour lesquelles elles pourraient être utiles plus tard (vous avez oublié pourquoi vous ajoutiez une fonctionnalité, localisez les fichiers manquants, etc.)

Voici une question connexe concernant l'objectif des messages de validation: Pourquoi devrais-je écrire un message de validation

Je m'engage toujours avec un message significatif sur les changements, et je le fais fréquemment avec des changements incrémentiels.

Est-ce toujours la chose la plus utile? Non, cela ne pose aucun problème. Si vous devez revenir à une étape précédente en cours, vos messages vous indiqueront où vous êtes et ce que vous avez fait. Il peut également être utilisé pour suivre l'avancement d'un projet. En ce qui concerne le fait qu'il soit considéré comme une perte de temps, les 30 secondes qu'il faut pour écrire une phrase sont-elles vraiment conséquentes?

Je ne vois aucune différence concernant les messages de validation, que vous travailliez en équipe ou non. Vous vous souvenez de ce que vous avez fait ici ou là pendant un temps limité, et après, c'est la même chose que si quelqu'un d'autre l'a écrit. Vous devez donc rédiger des messages aussi bons que vous le feriez pour les autres personnes.