Risposte:
Gli strumenti di controllo della versione sono abbastanza potenti da consentire alla persona di vedere quali file sono stati modificati e quali metodi sono stati aggiunti. Significa che in generale i messaggi di registro che duplicano chiaramente ciò che già esiste stanno inquinando il registro.
Hai aggiunto il somefuncmetodo per soddisfare un requisito, ovvero:
Ciò significa che i tuoi messaggi di log devono piuttosto spiegare quali funzionalità / bug sono stati interessati o qual è lo scopo del refactoring.
Non dimenticare di aggiungere il BIGLIETTO / NUMERO DI EMISSIONE .
Se hai qualche funzione o sistema di tracciamento dei problemi con un ticket # o numero di emissione , assicurati di inserire quell'ID # nel commit. Questo aiuterà chiunque desideri saperne di più sulla funzione o sul problema su cui stavi lavorando.
Nel mio ultimo progetto, c'era una macro che è stata sviluppata per assicurarsi che le prime 7 cifre del commento fossero un numero di emissione valido da una missione chiara (il nostro sistema di tracciamento di problemi / funzionalità).
Faccio quel tipo di cose quando commetto, ad esempio la correzione di un difetto che ha richiesto modifiche a più file. Questo rende un po 'più facile dire cosa è effettivamente cambiato senza guardare i singoli file nel changeset.
Per i changeset di un singolo file, questo non è necessario.
La prima riga è sempre una descrizione di alto livello del changeset, come un collegamento al difetto o alla user story.
Se sono informazioni rilevanti nella narrativa del messaggio di commit, allora sì, includerle. Se l'unica informazione è il nome file stesso, allora no.
Ad esempio, ciò ha senso: "Spostato la funzione build_foo () da fooutil.c a foobase.c, poiché la maggior parte dei programmi che vogliono usare build_foo () includono già foobase.c"
Questo non: "Aggiornato build_foo () in fooutil.c per prendere un parametro bar."
Voglio aggiungere una prospettiva diversa qui.
La mia risposta è Sì o No. Ma generalmente direi Sì.
Il controllo della versione è effettivamente abbastanza potente da sapere quale file viene aggiornato. Ma quando lo facciamo
$ git log
Vediamo solo il messaggio di commit. Questo è quello che fanno molte persone.
Guardando nel registro stesso. Aggiunge ulteriore contesto ad esso. Per esempio:
readme.md: Fix typo detected by language tool
È meglio di
Fix typo detected by language tool
Tuttavia, se le modifiche generano più file, almeno menziona il componente che viene modificato.
API: Fix reset password not sent email to user
Leggendolo, sappiamo che l'errore da correggere si trova nel componente API e probabilmente si trova nella directory API nella base di codice.
Potremmo comunque farlo
$ git show COMMIT_ID --name-only
ma aggiunge più passaggi solo per ottenere i file.
L'unica volta che ho visto che ciò è utile per un singolo check-in di file è se hai apportato modifiche a una funzione utilizzata in molti punti all'interno del file con il risultato che il diff è disordinato. Anche allora metterei prima il tracker delle modifiche # e una descrizione in chiaro del cambiamento.
Penso che la vera domanda qui sia quanto siano limitati i tuoi impegni? Se aspetti di eseguire il commit di una varietà di modifiche non correlate insieme in un unico commit, potresti sentire la necessità di specificare quali file sono stati modificati per quale scopo.
Tuttavia, se hai semplicemente eseguito commit più ristretti più frequentemente, un singolo commit spiegherebbe quali file sono stati modificati e potresti semplicemente descrivere quale fosse lo scopo nel messaggio.
Più impegni, più spesso. Questo è il modo in cui puoi evitare di essere così prolisso nei tuoi messaggi.