Bonjour,
J'utilise etckeeper avec git pour gérer la conf de mes machines.
Et je me posais la question des messages de commit pour qu'il soit claire.
Alors vous, sysadmin et autres utilisateurs de git du coin, avez-vous des conventions, ou des idées de conventions pour les commits de Etckeeper ?
J'ai fait quelque recherche pour les conventions de commit, mais c'est orienté développeurs, ce qui je trouve ne s'adapte pas bien au sysadmin.
Étant pas spécialement à l'aise en anglais, j'aimerais évité les messages en anglais ou franglais.
# ca depend du contexte
Posté par NeoX . Évalué à 2.
si c'est en réponse à un ticket client ou en interne à ta boite,
un commit avec
me semble deja un bon depart.
tu peux reprendre le No du ticket dans les commentaires là ou tu as fais les modifications, avec tes initiales par exemple
comme ca tu sais QUAND:QUI:POURQUOI la modification a été faite
maitenant si c'est pour TOI, ton labo perso,
ben tu peux omettre le QUI puis ce sera toujours TOI
reste le QUAND et POURQUOI
[^] # Re: ca depend du contexte
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Neox,
Ne le prends pas personnellement, mais pour moi, je ne trouve pas intéressant de mettre des commentaires d'historiques. Au bout d'un moment, on se retrouve avec tout un tas de commentaires d'historiques et quand je suis en train de regarder le code, ça ne m'intéresse pas (la plupart du temps) de savoir qu'on a modifié telle partie à telle époque et pour telle raison. Si ça a été fait, c'est que maintenant en avril 2020 c'est comme ça que ça doit fonctionner. D'autant plus que probablement (c'est la loi de Murphy) la partie qui m'intéresse de toute manière n'aura pas de commentaire d'historique.
Alors si je veux savoir ce qui s'est passé, je vais regarder l'historique de git et je fais des diff : c'est une des fonctions de base de git que j'utilise fréquemment.
Maintenant, on a tous nos manières et c'est à kosnik de trouver celle qui lui va le mieux, pour ma part je proscris les commentaires d'historiques ! ;-)
[^] # Re: ca depend du contexte
Posté par kosnik . Évalué à 1.
Je trouve également que les commentaire d'historique ça alourdi le message et fait doublon avec le diff.
Après certes c'est à moi de trouve ce qui me correspond, mais j'aimerais avoir des retours expériences pour voir ce qui ce fait ailleurs, et faire mon trie.
[^] # Re: ca depend du contexte
Posté par NeoX . Évalué à 2.
je suis d'accord que le GIT ET le commentaire dans le fichier font doublons,
mais je suis du principe que GIT peut ne plus être accessible (cas d'un backup des fichiers mais pas du depot)
que parfois transférer 500Go de Git pour récupérer une arborescence pratique de 50Mo, c'est un peu overkill.
et que donc le fichier commenté expliquant pourquoi il est fait ainsi doit se suffire.
de plus, savoir que telle ligne a été mise en 2015, est peut-être plus pratique que de rien y avoir et de deviner si en 2020 elle peut être encore d'actualité.
évidemment dans les commentaires on peut ne pas mettre toutes les modifications si c'est sur la meme ligne qui est modifiée, après plusieurs essais.
[^] # Re: ca depend du contexte
Posté par kosnik . Évalué à 1.
C'est sur que je vue comme ça, ça peut avoir son utilité.
Je ne me permettais pas de jugé ton utilisation des commit, mais de définir mon cas d'utilisation.
[^] # Re: ca depend du contexte
Posté par kosnik . Évalué à 1.
Effectivement, j'ai oublié de le précisé c'est pour du perso, en mono-utilisateur.
Pour précisé, c'est surtout pour le sujet (la 1ére ligne du commit), je cherche un équivalant, des développeurs aux conventionnelle hotfix, add, feature…
[^] # Re: ca depend du contexte
Posté par Nonolapéro . Évalué à 3.
Peut-être t’inspirer de ça : https://chris.beams.io/posts/git-commit/
[^] # Re: ca depend du contexte
Posté par kosnik . Évalué à 1.
Ça m'a l'ai d’être un bon début.
Merci pour la suggestion
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.