Non ho mai avuto la possibilità di lavorare con un team su un repository, quindi mi chiedo se c'è un modo corretto per documentare le modifiche.Repository Commit Msg Etiquette
Ad esempio, forse aggiungere un tag (s) come: bugfix, update, implementare? Solo curioso di sapere come i professionisti descrivono i loro impegni.
Speriamo che mi sarà aiutare a mantenere il progetto organizzato ...
Dovrebbe essere chiaro, descrizione sintetica del ciò che è stato cambiato o attuate in quel commit. Se hai integrato un sistema di tracciamento dei problemi, è utile anche il numero del problema.
La linea di fondo è, il messaggio dovrebbe avere senso per a) altre persone, in modo che capiscano cosa è stato fatto senza guardare il codice, e b) te stesso, quando si guarda il registro un anno dopo cercando di trovare dove hai risolto il bug con il foobar.
esempio di un buon messaggio:
Fixed the bug where the program would crash if the number of entries was zero (issue #2857)
Esempio di un cattivo messaggio:
Fixed email bug
Ci sono diversi approcci a questo, alcune persone non hanno nemmeno usare commettono messaggi, ma commettono un File ChangeLog insieme al resto (non lo consiglierei comunque, è doloroso unire tutto il tempo). Sono d'accordo con Michael per tutto il tempo, volevo solo sottolineare che diversi ambienti sono più o meno utili quando si tratta di inviare messaggi, ad esempio git ha un certain preference come dovrebbero apparire i messaggi.
Se si utilizza trac ad esempio, ti aiuterà a inserire il numero del biglietto lì con una certa sintassi (es. # 1234, almeno credo che lo sia), che lo farà apparire come un collegamento ipertestuale quando viene visualizzato nella cronologia di trac.
Il più verboso possibile è sempre l'idea migliore.
Assicurati anche di commentare rami, tag e fusioni, correttamente. Ti farà risparmiare mal di testa.
cioè MERGE: [from location] [Start repo #] : [end repo #] - [additional comments]
Commit commenti dovrebbe contenere una breve descrizione di quello hai fatto e perché l'avete fatto, senza dettagli sul come: se qualcuno ha bisogno di questo tipo di informazioni, può guardare la diff. Non riempire i commenti con dettagli di implementazione ridondanti.