Je suis un committer habituel et j'ai trouvé que cela me convenait, mais mes messages de commit sont presque toujours du type,
Age: 9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.
Je ne peux donc pas dire avec exactitude que des commits aussi fréquents et habituels dans ma branche (mercurial) ont encouragé les journaux de commit les plus détaillés. Parfois, je commets même le code à moitié terminé si, par exemple, ma femme me demande de sortir pour le dîner et que je copie simplement à la hâte et utilise le message de validation précédent "Travailler sur [...]".
Mes modèles de journal de validation sont généralement les suivants: "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"
D'un autre côté, cela m'a sauvé les fesses. Parfois, je rencontre un cas extrême que je n'avais ni anticipé ni testé. À ce stade, les commits fréquents m'aident à comprendre exactement où j'ai introduit l'erreur.
Donc, je ne connais pas les meilleures habitudes et je ne suis certainement pas du genre à écouter autant que possible les habitudes de consignation, mais je peux certainement dire que s’engager plus souvent peut certainement aider à régulariser la régression.
Chaque changement d'une ligne doit-il avoir un commit?
J'ai déjà effectué des modifications sur une ligne, mais généralement difficiles et je manquais peut-être de temps. Mes commits ne ressemblent pas toujours à des unités de travail ou de changement parfaites et complètes. Comme dit, parfois, ils sont juste le résultat de ma femme me demandant de sortir pour le dîner de façon inattendue.
Bon nombre de mes commits qui suivent ce "Working on [...]"modèle de log ne modélisent pas des unités de changement cohérentes (pourquoi je ne peux souvent pas mieux faire passer un message que "Working on [...]"), mais simplement le résultat de ma respiration, comme celle de me préparer une tasse de café. Le "Completed [...]"message indique la fin de cette unité de travail, et j’écris souvent un message beaucoup plus détaillé avec les premiers "Started working on [...]"messages de type lorsque je commence à travailler sur quelque chose. Si vous commettez en moyenne comme une fois toutes les 15 minutes, alors les messages "Travailler sur [...]" ressemblent davantage à des inter-intermédiaires pour ce que quelqu'un pourrait commettre dans une validation plus volumineuse avec un message plus détaillé.
Devrais-je m'engager avant tout test (par exemple, au moins pour les erreurs de syntaxe / compilation et ensuite pour l'annuler totalement; car l'idée n'a pas fonctionné ou le message est un mensonge)?
Je me contente de le commettre avant même d'exécuter des tests parfois (encore une fois si j'avais un événement imprévu). De plus, même si je suis en solo, je pousse sur un serveur (un seul fonctionnant ici chez moi sur un réseau local) qui prend en charge le CI. Cela peut sembler exagéré, mais bon, je me suis tellement habitué à m'appuyer là-dessus dans mes anciens lieux de travail. De plus, je ne veux pas être dérangé d'avoir à exécuter tous les tests unitaires et d'intégration à la main à chaque fois. J'aime avoir tout cela lié à juste pousser. Si un test échoue, il est assez facile de travailler de manière avant-gardiste où je fais la régression, corrige l'erreur dans le dernier tour, et continue. Cela dit, au moins, je construis le code par rapport à une version de débogage avant de valider.
Dois-je m'assurer de m'engager chaque matin / après-midi avant d'arrêter de travailler pour le dîner alors qu'il est encore frais?
J'aime m'engager avant de sortir et de faire une pause entre la programmation. Je n’ai pas vraiment réfléchi à pourquoi jusqu’à ce que j’aie rencontré cette question. Je suppose que c'est pour m'empêcher de reprendre là où je me suis arrêté sans journal de validation à la place de l'endroit où je me suis arrêté que je peux me permettre de faire la différence et ainsi de suite. Hmm, je dois vous revenir là-dessus car ce n'est peut-être pas théoriquement nécessaire compte tenu de la fréquence à laquelle je commets. Je me sens toujours plus à l'aise pour engager et pousser avant de quitter l'ordinateur pour une raison quelconque. Certains pourraient être que l'ancienne peur psychologique de, par exemple, l’ordinateur s’enflamme après mon départ et que les chefs de projet reviennent à l’époque où nous utilisions SVN avec les développeurs parfois pendant des semaines sans commettre de souffler dans notre cou et de nous rappeler constamment de vérifier le code le plus souvent possible tout en nous rappelant que notre code est la propriété de l'entreprise. De plus, c'est un peu plus efficace, en particulier pour ce qui est de faire en sorte que mon processus de CI puisse commencer à exécuter tous les tests en mon absence, afin de pouvoir revenir voir les résultats.
Oh, et parfois je me saoule un peu après mon départ et c’est en général une mauvaise idée d’essayer d’écrire un code complexe tout en étant saoul (mais pas toujours; j’ai créé un système de menu contextuel vraiment sympa après un moment de boisson en état d'ivresse, mais je n'avais que 6 bières et ce n'était pas si complexe à coder). Si j'essaie de faire cela, au moins j'ai commis le code écrit sobrement avant de partir pour revenir au lieu de mélanger le code ivre avec le code sobre, à quel point mon journal de commit pourrait se lire comme "Reverting back to code written before Jagermeister shots."ceci , je ne le fais pas très souvent, à moins que je ne sois inspiré par du code ivre, mais dans ces rares cas, le fait d’avoir commis quelque chose avant de sortir et de me saouler m'a vraiment aidé.