Nella prima riga di un messaggio di commit git ho l'abitudine di menzionare il file che viene modificato se una modifica non si estende su più file, ad esempio:
Add [somefunc] to [somefile]
È una cosa buona da fare o è inutile?
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 metodo somefunc per soddisfare un requisito, ad esempio:
Questo significa che i tuoi messaggi di log devono piuttosto spiegare quali caratteristiche / bug sono stati influenzati o quale era lo scopo del refactoring.
No. Esistono molti modi per esaminare i contenuti di un commit. Il commento dovrebbe descrivere lo scopo del commit.
Non dimenticare di aggiungere BIGLIETTO / NUMERO NUMERO .
Se possiedi un sistema di tracciamento di funzioni o problemi con un numero di ticket o un numero # , assicurati di inserire tale ID # nel commit. Ciò aiuterà chiunque desideri saperne di più sulla funzione o il 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 rilascio valido da clear quest (il nostro sistema di tracciamento di problemi / funzionalità).
Faccio quel tipo di cosa quando mi sto impegnando, ad es. la correzione per un difetto che richiedeva modifiche a più file. Questo rende un po 'più facile dire cosa è effettivamente cambiato senza guardare i singoli file nel changeset.
Per i singoli changeset di file, questo non è necessario.
La prima riga è sempre una descrizione di alto livello del changeset, come un collegamento al difetto o alla storia dell'utente.
Se si tratta di informazioni rilevanti nella narrativa del messaggio di commit, allora sì, includilo. Se l'unico bit di informazione è il nome del file stesso, allora no.
Ad esempio questo ha senso: "Spostata 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 no: "Aggiornato il build_foo () in fooutil.c per prendere un parametro bar."
L'unica volta che ho visto che questo è utile per un singolo file di checkin è se hai apportato delle modifiche a una funzione utilizzata in molti punti all'interno del file con il risultato che il diff è confuso. Anche in quel caso inserirò il change tracker # e una descrizione in testo semplice della modifica.
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. Quello che fa la maggior parte delle persone.
Esaminando il log stesso. Aggiunge ulteriore contesto ad esso. Ad esempio:
readme.md: Fix typo detected by language tool
È migliore di
Fix typo detected by language tool
Tuttavia, se le modifiche generano più file, allora menziona almeno il componente che si sta modificando.
API: Fix reset password not sent email to user
Leggendolo, sappiamo che l'errore che viene corretto è nel componente API e probabilmente nella directory API al codice base.
Potremmo tuttavia fare
$ git show COMMIT_ID --name-only
ma aggiunge altro passo solo per ottenere i file.
Penso che la vera domanda qui sia quanto limitati sono i tuoi impegni? Se aspetti di commettere una serie di modifiche non correlate insieme in un unico commit, allora potresti sentire la necessità di specificare quali file sono stati modificati per quale scopo.
Tuttavia, se si eseguivano semplicemente più commit più stretti, un singolo commit spiegherebbe quali file sono stati modificati e si potrebbe semplicemente descrivere quale fosse lo scopo del messaggio.
Più impegni, più spesso. Questo è il modo in cui puoi evitare di essere così prolisso nei tuoi messaggi.
Non dovrebbe
Chiunque sia interessato può vedere i cambiamenti in una cronologia
Inoltre non è fattibile nei sistemi più grandi dato che molti file potrebbero essere generati automaticamente
Leggi altre domande sui tag git