Scrivere messaggi di commit come sviluppatore solista?

Nei miei progetti in cui il repository è condiviso tra me e altri programmatori, scrivo sempre messaggi di commit anche se sono lo sviluppatore principale.

Ma su quei progetti in cui sono lo sviluppatore solista che lavora a un progetto e il repository è ospitato sul mio laptop personale e non è nemmeno ospitato dal client, quindi nessuno, tranne me stesso, vedrebbe i commit, dovrei ancora scrivere commit messaggi?

Finora li ho scritti, ma ho scoperto che non sono mai tornato indietro e ho visto i miei messaggi di commit. Mi prendo un po 'di tempo libero dallo sviluppo per scrivere i messaggi, ma poi non li vedo mai più nemmeno da me.

Ci sono buone ragioni per scrivere messaggi di commit come sviluppatore solista o dovresti semplicemente saltarli a favore di rimanere concentrati sullo sviluppo?

Bene, ecco una ragione: se improvvisamente ti rendi conto che qualcosa è stato rotto per le ultime centinaia di commit (possibile se commetti ad ogni modifica minore, meno fattibile se, come me, commetti solo istantanee "stabili"), puoi più facilmente trova dove hai inserito il bug se hai scritto messaggi di commit chiari, piuttosto che "correzioni di bug". (Credo che la stringa preferita di un collega). Certo, puoi andare con svn logo con qualunque SCM che stai usando, ma dovrebbe essere più semplice viceversa.

Anche i messaggi di commit ti costringono a pensare cosa hai fatto esattamente come un cambiamento e, credo, riassumendo nella tua mente come sarebbe meglio continuare a migliorare il progetto.

Ci provo sempre. Quante volte ti guardi indietro e pensi "Amico, cosa stavo facendo quando ho fatto questo cambiamento". Lo faccio sempre. 30 secondi di scrittura di un messaggio possono farti risparmiare 20 minuti di lavoro cercando di ricordare.

Credi sinceramente che il sovraccarico di digitare da 40 a 80 caratteri in un inglese semplice sia un sovraccarico significativo per un commit o stai cercando una scusa per essere pigro?

Forse il tuo problema sta esprimendo in parole povere il motivo per cui hai apportato la modifica, nel qual caso potresti dover rivedere lo scopo della modifica, anche al punto di chiederti se hai davvero bisogno di farlo.

Il mio consiglio è di non pensare che, poiché stai volando da solo, puoi infrangere le regole. Rimani sempre professionale e aggiungi messaggi di commit significativi. Come notato da altri ripetitori, un giorno ne sarai grato.

• Non sarai sempre uno sviluppatore solista.

• Alla fine spezzerai la tua base di codice e tenterai di ripristinarla. Buoni messaggi di commit ti faranno risparmiare ore.

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

• I messaggi di commit dovrebbero essere molto chiari. In caso contrario, non hai finito di lavorare su un'attività o una singola attività si è estesa su due o più attività.

Sicuramente, altrimenti rendi le funzioni come la ramificazione e l'unione molto più difficili da usare. E voi avrete voglia di usarli, anche se lo sviluppatore solista.

Una possibile ragione per: ti costringe a pensare in modo più astratto al cambiamento che hai appena fatto e a strutturare i cambiamenti.

Se ti sembra inutile, forse commenta solo i principali cambiamenti, o quelli che cambiano la funzionalità esistente, nel caso in cui cerchi la fonte di un comportamento strano.

Sono stato l'unico committer del progetto TXR e ho tenuto un ChangeLog dettagliato fin dall'inizio del progetto. Questo è vicino a circa 11.000 linee e in crescita: http://www.kylheku.com/cgit/txr/tree/ChangeLog

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

[Modifica del 2016: da metà 2015 non mantengo più un file ChangeLog; tuttavia, i messaggi di commit sono scritti in un formato conforme alle convenzioni Git e ChangeLog contemporaneamente. Lo stesso livello di dettaglio è presente, in un modo che non causa problemi di unione. 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 capire cosa stavo facendo.

Nel ChangeLog puoi sapere 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 scrivere messaggi di commit dettagliati come questi quando si lavora da soli è questo: si trovano bug quando si esegue questa operazione .

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 recensione di commit non è tanto che qualcuno sta controllando il tuo codice, ma che devi spiegare le tue modifiche a un altro sviluppatore.

Quando provi a spiegare le cose, a volte scopri che non hanno senso.

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

A volte ho apportato modifiche, quando nel mezzo della scrittura della voce ChangeLog mi sono reso conto che questo sarebbe stato un git reset --hard(buttare via questi cambiamenti 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 funzione, individuando i file mancanti, ecc.)

Ecco una domanda correlata relativa allo scopo dei messaggi di commit: Perché dovrei scrivere un messaggio di commit

Mi impegno sempre con un messaggio significativo sulle modifiche e lo faccio spesso con modifiche incrementali.

Questa è sempre la cosa più utile? No, non c'è nessun problema nel farlo. Se devi tornare a una fase precedente in corso, i tuoi messaggi ti faranno sapere dove ti trovi e cosa hai fatto. Può anche essere usato per tenere traccia dei progressi di un progetto. Per quanto riguarda la perdita di tempo, i 30 secondi necessari per annotare una frase sono davvero così consequenziali?

Non vedo alcuna differenza per quanto riguarda i messaggi di commit, sia che tu stia lavorando in un team o meno. Ricordi cosa hai fatto qui o lì solo per un periodo di tempo limitato, e dopo è lo stesso che se fosse stato scritto da qualcun altro. Quindi dovresti scrivere messaggi buoni come faresti con le altre persone.