Per rispondere a questa domanda, concordiamo su questa definizione di "messaggio di buona comunicazione" da qui :
Your comment should be brief and to the point, describing what was changed and possibly why.
e accetta che fare riferimento a un bug / problema in un messaggio di commit sia una buona cosa.
Ora, ci sono molti strumenti che si integrano con i repository VCS e, per farli funzionare, richiedono che i messaggi di commit contengano varie "informazioni di controllo" che generalmente non aggiungono valore in senso storico? Pensate,
- Quantità di tempo impiegato per risolvere un problema (
[Spent: 4h]) - A / cc per notificare altri membri del team del changeset (
/cc john, jill) - Un tag sul server CI per distribuire il changeset su sviluppo / staging / produzione (
[deploy: production]) - Impostazione di un revisore (
R: jill)
Certo, tutto questo è molto conveniente per gli sviluppatori a breve termine (perché lasciare la console per premere un pulsante nell'interfaccia CI quando posso aggiungere una breve stringa al messaggio di commit), ma trovo che questi messaggi ingombrino troppo il changelog e anche troppo specifico dell'infrastruttura (cosa succede se passiamo ad un Time Tracker che usa una sintassi leggermente diversa?).
Cosa ne pensi di questi messaggi e dove traccia la linea su cosa accettare e cosa proibire?