Sono un committer abituale e ho scoperto che mi andava bene, ma è vero che i miei messaggi di commit sono quasi sempre come,
Age: 9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.
Quindi non posso dire con esattezza che effettuare commit così frequenti e abituali nella mia filiale (mercuriale) abbia incoraggiato esattamente i log di commit più dettagliati. A volte commetto anche il codice a metà, se, per esempio, mia moglie mi chiede di uscire a cena, a quel punto copierò in fretta e userò il precedente messaggio "Lavorando su [...]".
I miei modelli di log di commit sono in genere come, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"
Il rovescio della medaglia però, mi ha salvato il culo. A volte mi imbatto in un caso limite che non avevo previsto e testato contro, a quel punto i frequenti commit mi aiutano a capire esattamente dove ho introdotto l'errore.
Quindi non conosco le migliori abitudini e non sono certo uno che ascolta per quanto riguarda le abitudini ideali di registrazione dei commit, ma posso sicuramente dire che impegnarsi più frequentemente può sicuramente aiutare quando è necessario eseguire una regressione.
Ogni modifica di una riga dovrebbe ricevere un commit?
Ho già apportato modifiche di una riga prima, ma di solito complicate e forse avevo poco tempo. I miei impegni non assomigliano sempre a unità di lavoro o cambiamenti perfetti e completi. Come detto, a volte sono solo il risultato di mia moglie che mi chiede di uscire a cena inaspettatamente.
Molti dei miei impegni di TBH che seguono quel "Working on [...]"modello di registro non modellano unità coerenti di cambiamento (perché spesso non riesco a trovare un messaggio migliore di "Working on [...]") ma solo il risultato di una pausa, come farmi una tazza di caffè. Il "Completed [...]"messaggio indica la fine di quell'unità di lavoro, e lì scrivo spesso un messaggio molto più dettagliato insieme ai messaggi di primo "Started working on [...]"tipo quando inizio a lavorare su qualcosa. Se in media commetti come una volta ogni 15 minuti, quei messaggi "Lavorando su [...]" sono più simili a quelli intermedi per ciò che qualcuno potrebbe commettere in un commit più voluminoso con un messaggio più dettagliato.
Devo impegnarmi prima di qualsiasi test (ad esempio, almeno per errori di sintassi / compilazione e quindi doverlo annullare completamente; poiché l'idea non ha funzionato o il messaggio è una bugia)?
Vado avanti e lo commetto anche prima di eseguire i test a volte (di nuovo se ho avuto un evento inaspettato). Anche se sono solo, invio a un server (solo uno in esecuzione qui a casa su una LAN) che esegue CI. Potrebbe sembrare eccessivo ma non so, mi sono abituato così tanto a appoggiarlo nei miei precedenti posti di lavoro. Inoltre, non voglio preoccuparmi di dover eseguire manualmente tutte le mie unità e i test di integrazione. Mi piace avere tutto legato solo alla spinta. Se un test fallisce è abbastanza facile lavorare in un modo che procede in avanti dove faccio la regressione, correggere l'errore nell'ultimo giro e andare avanti. Detto questo, almeno costruisco il codice contro una build di debug prima di impegnarmi.
Devo assicurarmi di impegnarmi ogni mattina / pomeriggio prima di smettere di lavorare per cena mentre è ancora fresco?
Mi piace impegnarmi prima di uscire e fare una pausa tra la programmazione. Non ho riflettuto molto sul perché esattamente fino a quando ho incontrato questa domanda. Suppongo sia per impedire a me stesso di riprendere da dove avevo interrotto senza un registro di commit lì al posto di dove avevo interrotto che posso diff e così via. Hmm, ho bisogno di ricontattarti dal momento che forse non è teoricamente necessario data la frequenza con cui mi impegno. Mi sento ancora più a mio agio a impegnarmi e spingere prima di lasciare il computer per qualsiasi motivo. In parte potrebbe essere quella precedente paura psicologica di, diciamo, il computer prende fuoco dopo che me ne vado e avendo i project manager nei giorni in cui stavamo usando SVN con gli sviluppatori a volte andando per settimane senza impegnarci a respirare giù per il collo e ricordarci costantemente di controllare il codice il più spesso possibile ricordandoci che il nostro codice è di proprietà dell'azienda. Inoltre è un po 'più efficiente soprattutto con la spinta in modo che il mio processo di CI possa iniziare a eseguire tutti i test mentre sono via in modo da poter tornare e vedere i risultati.
Oh, a volte mi ubriaco un po 'dopo che me ne vado ed è di solito una cattiva idea provare a scrivere un codice complesso mentre sono ubriaco (anche se non sempre; una volta ho trovato un sistema di menu di scelta rapida davvero piacevole dopo aver avuto un momento eureka mentre ero ubriaco, ma avevo solo 6 birre e non era così complicato da codificare). Se provo a farlo, almeno ho commesso il codice scritto in modo sobrio prima di partire per tornare indietro invece di mescolare il codice ubriaco con il codice sobrio, a quel punto il mio registro di commit potrebbe essere simile, "Reverting back to code written before Jagermeister shots."non lo faccio molto spesso, a meno che non mi sia ispirata al codice dell'ubriaco, ma in quei rari casi, mi ha davvero aiutato a commettere qualcosa prima di uscire e ubriacarmi.