Commentare in maniera appropriata ogni check-in

L'operazione di check-in applicata su un insieme di modifiche le rende pubbliche e disponibili agli altri membri del gruppo di sviluppo. Gli strumenti di versionamento permettono di verificare con estrema semplicità le modifiche effettuate; non è altrettanto semplice capire che effetto hanno o dovrebbero avere tali modifiche.
Per questo motivo è possibile associare al check-in un commento, che ha lo scopo di descrivere le modifiche inserite e l'effetto dichiarato che hanno rispetto all'intero progetto. Il commento deve essere chiaro, sintetico ma allo stesso tempo esauriente.
Una pratica molto utile è quella di inserire nel commento un riferimento ad un sistema esterno di gestione delle attività. Ad esempio, se inserisco nel sistema di gestione delle attività un difetto da risolvere, posso inserire nel commento l'ID associato al difetto. O magari direttamente l'indirizzo http alla descrizione e storia del difetto.
Sicuramente quello che sconsiglio è di effettuare dei check-in senza commenti. Fanno perdere molto tempo quando si guarda la storia delle modifiche di un file e fanno innervosire chi deve capire in poco tempo quando e come una certa funzionalità è stata modificata.
Probabilmente come nel caso di check-in che rompono il codice versionato, dei dissuasori sociali possono aiutare ad evitare l'assenza di commenti. Esiste pure la possibilità di vietare check-in senza commenti, me ritengo più utile che sia lo scrupolo e l'attenzione dei membri del gruppo a ricordare l'uso dei commenti.

Per una consulenza sul versionamento dei progetti software contattami su poderico@gmail.com.