Scrive messaggi di commit come sviluppatore solista?

Ecco una ragione: se all'improvviso ti rendi conto che qualcosa è stato infranto per le ultime centinaia di commit (possibile se ti impegni in ogni modifica minore, meno fattibile se tu, come me, impegni solo istantanee "stabili"), puoi trovare più facilmente dove hai inserito il bug se hai scritto messaggi di commit chiari, piuttosto che "bugfix". (Stringa preferita di un collega, credo). Certo, puoi andare con svn log o qualunque SCM stai usando, ma dovrebbe essere più semplice al contrario.

Inoltre, i messaggi di commit ti costringono a pensare a ciò che esattamente hai fatto come cambiamento e, credo, riassumendo nella tua mente come sarebbe meglio continuare a migliorare il progetto.

Cerco di sempre. Quante volte ti guardi indietro e pensi "Man quello che stavo facendo quando ho apportato questo cambiamento". Io faccio tutto il tempo 30 secondi di scrittura di un messaggio possono farti risparmiare 20 minuti di lavoro che cercano di ricordare.

Credi onestamente che l'overhead di digitare da 40 a 80 caratteri in inglese è un overhead significativo per un commit, o stai cercando una scusa per essere pigro?

Forse il tuo problema sta esprimendo in puro inglese perché hai apportato la modifica, nel qual caso potresti aver bisogno di rivedere lo scopo del cambiamento, anche al punto di chiedertelo, hai davvero bisogno di farlo.

Il mio consiglio è di non pensare che, poiché stai volando da solo, puoi infrangere le regole. Rimanere professionale in ogni momento e aggiungere messaggi di commit significativi. Come notato da altri reponders, un giorno ne sarete grati.

• Non sarai sempre uno sviluppatore solista.

• Alla fine si rompe il codice base e si tenta di ripristinarlo. I buoni messaggi di commit ti faranno risparmiare ore.

• Non riesci a ricordare a cosa stavi lavorando tre settimane fa, giusto?

• I messaggi di commit dovrebbero essere molto chiari. Se non lo sono, allora non hai finito di lavorare su un'attività, o una singola attività si è diffusa su due o più attività.

Sicuramente, altrimenti si rendono più difficili da usare funzionalità come ramificazione e fusione. E tu vorrà usarli, anche se sviluppatore solista.

Una possibile ragione per: ti costringe a pensare in modo più astratto alla modifica che hai appena fatto e a modificare le strutture.

Se ti sembra inutile, forse commenta solo le modifiche principali, o quelle che cambiano la funzionalità esistente, nel caso tu stia cercando l'origine di un comportamento strano.

Sono stato l'unico responsabile del progetto TXR, e ho mantenuto un ChangeLog dettagliato fin dall'inizio del progetto. Questo è vicino a 11.000 linee lunghe e in crescita: link

(I messaggi di commit nel repository sono solo una copia di ciò che accade nel ChangeLog.)

[modifica 2016: a partire dalla metà del 2015, non conservo più un file ChangeLog; tuttavia, i messaggi di commit sono scritti in un formato conforme alle convenzioni Git e ChangeLog allo stesso tempo. Lo stesso livello di dettaglio è lì, in un modo che non causa problemi di fusione. Un file ChangeLog potrebbe essere ricostruito meccanicamente da questi commenti.]

Sì, più di una volta sono tornato a un vecchio messaggio di commit associato a una modifica che ha rotto qualcosa (scoperto con l'aiuto di git bisect ). Il messaggio mi ha aiutato a dare un senso a quello che stavo facendo.

Nel ChangeLog puoi dire quando una funzione, tipo, macro o variabile globale è stata introdotta per la prima volta e quando è stata successivamente toccata dalle modifiche.

Ma il motivo principale per cui scrivi dettaglia tieni messaggi come questi quando lavori da solo è questo: trovi bug quando fai questo .

Scrivere un messaggio di commit dettagliato ha vantaggi simili a una revisione del codice del commit da parte di qualcun altro. Il valore in una revisione di commit non è tanto che qualcuno sta controllando il tuo codice, ma devi spiegare le tue modifiche a un altro sviluppatore.

Quando cerchi di spiegare le cose, a volte trovi che non hanno senso.

Un altro motivo: puoi sorprenderti a fare un cambiamento inutile . Scrivendo un commento di commit dettagliato, acquisisci una visione di alto livello di ciò che stai facendo, quindi a volte ti trovi di fronte al fatto che non è un buon cambiamento.

A volte ho apportato delle modifiche, quando nel mezzo della scrittura della voce ChangeLog ho capito che questo sarebbe stato un git reset --hard (buttare via queste modifiche inutili) piuttosto che git commit -a .

Anche se non hai ancora riscontrato la necessità di visualizzare i tuoi messaggi di commit, potresti essere molto grato per loro in futuro. Dovresti continuare a scriverli anche per te stesso. Ci sono molte ragioni per cui potrebbero essere utili in seguito (hai dimenticato perché stavi aggiungendo una funzionalità, localizzi file mancanti, ecc.)

Ecco una domanda correlata riguardante lo scopo dei messaggi di commit: Perché Devo scrivere un messaggio di commit

Mi impegno sempre con un messaggio significativo sui cambiamenti, e lo faccio spesso con modifiche incrementali.

Questa è sempre la cosa più utile? No, non c'è alcun problema nel farlo. Se hai bisogno di tornare a una fase precedente, i tuoi messaggi ti faranno sapere dove sei e cosa hai fatto. Può anche essere utilizzato per tenere traccia dei progressi di un progetto. Per quanto sia visto come una perdita di tempo, sono i 30 secondi necessari per annotare una frase davvero così consequenziale?

Non vedo alcuna differenza riguardo ai messaggi di commit se lavori in una squadra o no. Ti ricordi cosa hai fatto qui o là solo per un tempo limitato, dopodiché è come se qualcun altro l'avesse scritto. Quindi dovresti scrivere messaggi come faresti per le altre persone.