Perché dovrei scrivere un messaggio di commit?

Perché dovrei scrivere un messaggio di commit? Non voglio e penso che sia stupido ogni volta.

Un frontend GUI che uso e che diventerà senza nome ti costringe a farlo. Sento altri farlo ogni volta anche se stanno usando il VCS sulla riga di comando.

Se mi impegno più volte al giorno e non ho finito una funzione di cosa sto scrivendo? Scrivo SOLO un messaggio dopo molti commit e sento che è tempo di un mini tag o quando faccio un tag vero.

Ho ragione o mi sto perdendo qualcosa? anche io sto usando un sistema distribuito

A tutte le persone che dicono "commetti solo quando hai un messaggio utile e ben ponderato da scrivere e quando la tua funzione è completa al 100% e hai dei test unitari per questo", dico: sei ancora nella mentalità SVN .

Se stai usando git , questo è ciò che definirei un flusso di lavoro intelligente:

1. Impegnati tutte le volte che vuoi . Scrivi qualsiasi vecchio messaggio veloce lì. Nessuno lo vedrà comunque.
2. Dopo dire, 10 commit, hai finito quella funzione su cui stavi lavorando. Ora scrivi i test e commetti quei test. O qualunque altra cosa tu voglia. Se ti piace TDD, scrivi prima i test, non mi interessa, né git.
3. git rebase -idal primo "disordinato" impegno aggiunto e corretto la cronologia locale comprimendo, modificando, omettendo e pulendo in altro modo la cronologia recente in commit logici e puliti con messaggi gradevoli .
4. Dopo la pulizia, chiedi a qualcuno di ritirarti.
5. Risciacqua e ripeti.

Nota che il passaggio 3 è quando finisci con quei bei commit che stavi cercando e che usando SVN dovresti astenervi dal commettere fino a quando non hai fatto i primi due passaggi, che è ciò che la maggior parte delle altre risposte sta suggerendo. IOW, non vuoi infliggere il tuo codice non scritto e non testato su altri, quindi non ti impegni per una settimana, fino a quando la tua funzione non sarà terminata. Non stai utilizzando il controllo versione al suo pieno potenziale.

Si noti inoltre che ovunque tra i passaggi 1 e 3, è possibile git pushapportare modifiche al proprio mirror repo privato sul server per ottenere backup gratuiti se l'HDD del laptop si spegne.

Perché quando un povero manutentore sta cercando un bug e scopre che è stato aggiunto in rev. xyz, vorrà sapere quale rev. xyz avrebbe dovuto farlo.

Commenta il tuo codice sorgente, giusto?

Scrivi i migliori commenti, quelli che dicono perché il codice dice solo come ?

Il messaggio di commit è un tale commento, quindi è molto importante e più si pensa a farlo nel modo giusto, più è utile per un futuro manutentore del software.

Per qualsiasi software attivo, questo particolare commento finirà per essere mostrato in qualcosa del genere

(disponibile su http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Ciò consente una visione a volo d'uccello di chi ha lavorato al software quando e cosa hanno fatto.

Si noti che questo è l'obiettivo finale del commento di commit, ovvero presentarsi in tale elenco che dice " cosa " al proprio sé futuro o al proprio collega, e QUESTO è il motivo per cui si dovrebbe occuparsi di scrivere buoni messaggi di commit.

Se il messaggio di commit ti sembra stupido, sembra che tu stia usando i commit errati.

Gli impegni dovrebbero essere effettuati per una buona ragione: dovrebbero essere correlati alle attività che hai suddiviso per la funzione su cui stai lavorando. Indipendentemente dal fatto che tali compiti siano formali o solo nella tua mente, ogni modifica che commetti dovrebbe più o meno completare un'attività e quindi essere funzionale in qualche modo.

Quindi i tuoi messaggi di commit hanno uno scopo molto migliore. Descrivi l'attività che hai completato e se non è stata rintracciata da qualche altra parte, perché tale attività era necessaria o quale scopo serve:

• Rifattorizzata la classe utente per un migliore incapsulamento
• Stub API creati in modo che le interfacce possano essere utilizzate nella classe controller
• Conversione della classe del database in una classe astratta in modo che un database simulato possa essere utilizzato in casi di test

Quindi tu o altri sviluppatori potete navigare nel repository o nella cronologia dei file e vedere abbastanza facilmente dove sono avvenute determinate evoluzioni e perché. Oppure, se una particolare revisione viene dichiarata colpevole di un bug, il messaggio di commit fornirà un indizio sul motivo per cui quella linea è stata inserita, in modo da non solo strapparla e possibile rigirare qualcosa che si pensava fosse risolto e puoi invece risolverlo nel modo giusto.

I commenti di commit non risolvono tutto. C'è sempre la possibilità che possano fuorviare tanto quanto aiutano, specialmente quando gli sviluppatori sono arrabbiati di doverli inserire. Prova questo: considerali come una scia di briciole di pane nei boschi o un waypoint alpinistico o proiettili traccianti. Fatto bene, possono delineare un percorso altrimenti confuso.

Non farne un grosso problema. Essere onesti:

• "Modifica entità dell'indice spaziale, Daos e UI per gestire la funzione X"
• "Check-in incrementale per richiesta funzionalità # 1234 e bug # 5678"
• "Ho rotto l'ultima build. Questi sono i file che ho perso."

Tienilo breve e "quadro generale". Se possibile, fare riferimento a un numero di problema nel sistema di funzionalità / bug. Alcune UI di controllo versione includono un campo per questo tipo di cose.

Riduce il numero di WTF / minuto;)

che si traduce in una squadra più felice (che non ti odia) e in una migliore produzione di squadra potenzialmente a costi inferiori

Quindi il resto del tuo team sa che WTF stai facendo il check-in delle modifiche all'albero del progetto.

perché se non ti eserciti a inserire messaggi di commit decenti, finirai come il mio collega che inserisce messaggi come

no changes

o

testing

per commit con oltre un centinaio di file modificati (non scherzo qui !!).

Se diventi un tale sviluppatore, sembrerai stupido agli occhi del resto del mondo, non importa quanto pensi che sia stupido semplicemente inserire un messaggio.

Perché ti impegni se le modifiche non sono significative?

Impegna solo le modifiche che hanno un significato. Ad esempio ho fatto un refactoring piuttosto grande l'altra settimana che mi ha richiesto circa 3 giorni. Avrei avuto un sacco di impegni durante quel periodo. Alcuni erano cambiamenti piuttosto piccoli ("ribattezzato la classe da X a Y per riflettere le nuove responsabilità" o "spostato il metodo Z () nella classe Q") e altri erano molto grandi. Quando ho finito con una caratteristica / refactoring, controllo se alcuni commit potrebbero essere schiacciati (almeno git lo supporta, non so altri strumenti), ma di solito li lascio così com'è perché aiuta in seguito.

Immagino che non ti impegneresti a modificare una linea, quindi dovrebbe avere un significato. Descrivi semplicemente cosa hai fatto dall'ultimo commit.

immagina una condizione quando hai rotto il sistema apportando alcune modifiche e realizzalo dopo diversi impegni da parte del team. Non ricordi quale sia stata la modifica, ma ricordi che qualcosa potrebbe andare storto quando stavi migliorando la funzione X o rimuovendo un file dal modulo Y.

Ma sfortunatamente il numero di revisione non ti dice quando hai cambiato X o Y. Quindi la tua scelta o leggi tutti i codici impegnati negli ultimi N giorni o semplicemente leggi i messaggi di commit dettagliati che hai scritto (molto più leggibili del codice).

Quindi, se scrivi lo stesso, noioso, inutile testo non correlato nel messaggio di commit, perché devi farlo, è più dannoso che avere un messaggio di commit. Perché invece di trovare la radice del bug, il messaggio sbagliato ti guiderà.

Quindi prova a scrivere messaggi di commit significativi ogni volta che commetti, il che può aiutare te e anche il manutentore.

Se stai lavorando con gli altri, i messaggi di commit sono molto importanti per vedere effettivamente cosa hanno fatto gli altri: cercare le differenze per ognuno di essi è molto più lavoro e potresti non riuscire a capire perché qualcuno lo abbia fatto. Se lavori con altri e qualcuno (forse non tu) deve effettivamente guardare indietro, ad esempio per tenere traccia del modo in cui il comportamento è cambiato dalla versione precedente in modi inaspettati ... stai davvero rendendo la vita difficile non usando un suggerimento utile nel commit Messaggio.

Se lavori da solo ... su un progetto che è per lo più codificato "così com'è" (ad esempio un singolo sito Web o script semplice) posso più o meno vedere da dove vieni. Se lavoro su qualcosa del genere, mi preoccupo solo della data / ora o delle modifiche più recenti quando continuo a lavorare su qualcosa (hai un punto su cui ripristinare, ma che conta solo durante lo sviluppo, non dopo averlo implementato). Il controllo della versione è solo un modo per fare backup con pochi problemi - concordo pienamente sul fatto che non sta facendo un uso completo del sistema - ma su alcuni progetti su piccola scala, che potrebbero non essere necessari.

L'idea mi è venuta in mente prima che il controllo versione venisse utilizzato in due modi diversi, uno per documentare i cambiamenti nel progetto e l'altro come aiuto per gli sviluppatori sul posto ... e quei due sono totalmente diversi l'uno dall'altro. I messaggi di commit sono molto importanti in un modo e potrebbero essere per lo più inutili nell'altro.

Ti stai perdendo qualcosa. Ci deve essere un motivo per eseguire un commit altrimenti non lo faresti.

Tutto quello che devi fare nel commento è di esprimere il motivo in parole, anche se solo wip: adding new state objects

Come molti altri, faccio un po 'di codice nel mio tempo libero e utilizzo un sistema di controllo delle revisioni per monitorare sia il mio sviluppo che i miei cambiamenti. La quantità di tempo libero che ho a disposizione varia notevolmente da settimana a settimana e da mese a mese. Molte sono state le occasioni in cui non avrei avuto il tempo di scrivere un codice su un progetto per settimane o addirittura mesi, e il tempo che avevo in genere andava da 10 minuti (giorno tipico) a 40 minuti (buona giornata). Quelle certamente non sono ottime condizioni, soprattutto per problemi di debug.

Era essenziale tenere appunti che non si sarebbero persi e sarebbero stati facilmente recuperabili. Alla fine di ogni sessione, il lavoro della sessione verrebbe eseguito con un messaggio dettagliato. Potrei quindi passare attraverso la cronologia degli impegni e tenere traccia dei miei progressi e del mio processo di pensiero. Questo mi ha permesso di riprendere da dove ero la settimana scorsa, o il mese scorso con il minor tempo prezioso perso.

Il punto che sto cercando di illustrare è che buoni messaggi di commit aiutano te (e chiunque altro venga dopo di te) a capire cosa è successo, cosa sta succedendo, dove stanno andando le cose e soprattutto perché.

Pensaci logicamente per un minuto. Quando commetti significa che qualcosa è stato fatto. Se non lasci nessun messaggio, come faranno gli altri a sapere cosa è stato fatto?

Se non commentate i vostri impegni, potreste essere tentati di commentare il cambiamento nella fonte. Nel tempo, ciò può ingombrare la fonte.

I messaggi di commit sono a modo rapido per sapere cosa sta succedendo in quel check-in e aiuteranno gli altri sviluppatori del tuo team quando vogliono sapere quale aspetto del codice è cambiato in quali revisioni (per motivi diversi).

In una nota correlata, suggerirei di specificare il numero del caso del tracker dei bug (spero che tu ne stia usando uno) nel messaggio di commit, in modo che sia utile per il futuro tracciare facilmente le cose.

In modo che il manutentore di quel codice 1 anno dopo sappia chi dare la caccia a quel codice atroce. :)