Des messages d'engagement petits ou grands ?

Question

Il y a quelques jours, un de mes amis et moi avons eu une discussion sur la taille d'un message de validation lors de l'utilisation de systèmes de contrôle de version. J'avais l'idée de commiter souvent et petit alors que lui, au contraire, utilisait des messages de commit plus grands mais commettait moins souvent.

J'ai toujours entendu dire que vous devriez, au moins en tant que débutant, faire les choses à ma façon ; des petits messages de commit souvent. Vous devriez, si possible, résumer votre commit en une phrase.

Mais j'ai le sentiment inverse quand je regarde des professionnels comme Linus Torvalds . Voici un message d'engagement de sa part sur le sous la surface sur github.

Il considère donc qu'ils sont identiques s'ils se situent dans un intervalle d'un demi bar l'une de l'autre. Si vous éditez les pressions à la main et que vous les réglez à la la même pression en bar que les échantillons, elles peuvent ne pas être identiques à la identique au dernier milli-bar, mais il est clair que la pression du cylindre saisie manuellement n'est pas n'est pas significativement différente des données de l'échantillon, donc considérez-la comme redondante.
Nous voulons que les modifications manuelles de la pression des cylindres aient la priorité sur les données d'échantillonnage (comme Dirk l'a fait). sur les données d'échantillonnage (comme Dirk le dit si bien, certains ordinateurs de plongée de plongée n'ont pas vraiment de données d'échantillonnage très fiables), mais en même temps, les données d'échantillonnage sont celles dont nous attendons une certaine précision. données d'échantillonnage sont celles dont nous attendons qu'elles soient assez précises. Le site pression de départ et d'arrivée servent lorsqu'il n'y a pas de données d'échantillon données d'échantillonnage, ou lorsque les données d'échantillonnage sont totalement fausses pour une raison quelconque.
Signé par : Linus Torvalds

Ici est le message de livraison en question.

J'ai jeté un coup d'œil à mes propres messages de validation (j'en ai quelques milliers) et ils font le plus souvent moins de 40 caractères.

Quelqu'un a-t-il un avis sur la question ?

Answer 1

Vous devez tenir compte du public auquel s'adressent vos messages d'engagement.

Si vous êtes la seule personne à s'intéresser à vos projets, écrivez aussi peu que vous le souhaitez - vous avez juste besoin d'en avoir assez pour vous rappeler pourquoi vous avez choisi une approche plutôt qu'une autre dans six mois. Vous avez juste besoin d'en avoir assez pour trouver quel commit spécifique a changé quelle fonctionnalité spécifique quand vous voulez faire la chasse aux bugs.

Si vous écrivez des logiciels avec une équipe qui peut servir des dizaines ou des centaines de personnes, les messages de livraison devraient probablement être plus significatifs. (Cela ne signifie pas toujours plus longtemps mais cela signifie que l'expression "corriger un bogue stupide" est à éviter à tout prix - "ne pas dépasser le tampon de pile 'nom'" est bien meilleure et presque aussi rapide à taper).

Les messages de commit de Linus peuvent sembler énormes, mais il ne l'est pas. verbeux o verbeux . Il est concis et va droit au but. Il écrit pour des milliers ou des millions de programmeurs, de distributeurs de paquets, et dans le message spécifique que vous avez trouvé, des plongeurs. qui dépendent de son code pour leur vie . Ils veulent des messages d'engagement de meilleure qualité que ceux que l'on peut exiger d'un joueur de MMORPG.

Answer 2

La taille des messages d'engagement a presque rien à faire avec la fréquence de vos engagements.

Le consensus général sur la fréquence des livraisons est que livrer souvent est mieux, mais que vous ne devez livrer que du code qui fonctionne (ou du moins qui se compile et ne casse rien).

Notez que git vous permet de "comprimer" plusieurs commits en un seul, de sorte que vous avez l'avantage de commiter souvent (ne pas avoir beaucoup de changements non commits à tout moment) et de ne commiter que des fonctionnalités complètes (historique des commits plus facilement compréhensible).

En ce qui concerne les messages de validation, il est toujours bon d'avoir plus d'informations, mais il faut bien sûr les mettre en balance avec l'effort que cela demande.

Le but d'un message de validation est de donner un très bref aperçu de ce qui a été modifié (afin que vous puissiez décider si c'est intéressant pour vous lorsque vous regardez l'historique des validations), et d'expliquer que pourquoi le changement dans le commit a été fait. Le message de Linus fait cela de manière très détaillée. Mais s'il existe une entrée correspondante dans un système de suivi des problèmes/bogues, ou un document de conception, il serait préférable de s'y référer.

Answer 3

Je préfère des messages de commit plus petits avec des commits atomiques. Livrez des changements petits et succincts. Ils ne nécessitent pas beaucoup d'explications. Écrivez le code, et s'il a besoin d'être expliqué, laissez les commentaires parler. Il est difficile de scanner des commits avec des messages énormes. Tant que vous expliquez l'essentiel de ce qui se passe, cela devrait suffire. Je pense que c'est une question de préférence personnelle.

Answer 4

La taille de mes commits dépend de mes tâches. J'essaie de regrouper les changements similaires dans un seul commit. Ainsi, les messages ne décrivent que les fonctionnalités que je développe (sans histoires longues et ennuyeuses).

Answer 5

Peu et souvent, c'est ce que je trouve le plus efficace.