Le migliori abitudini di controllo delle versioni per gli sviluppatori solisti?

Manca molto.

Anch'io sono solo, in un certo senso. Mi impegno ogni volta che apporto un cambiamento significativo, o prima di iniziarne uno significativo, così posso tornare indietro se rovino tutto e ogni tanto anche se non sto facendo nulla di grosso. Non tutti i giorni davvero, ma vicino. A volte un paio di volte al giorno.

Quello che ottengo è che posso tornare indietro ogni volta che voglio. Che è molto Inoltre, avere i rami ordinati aiuta.

Suppongo che mi dia un sacco di ordini.

Sto usando svn, e mi sto ammalando. Ma non puoi passare più tempo a imparare qualcos'altro.

Buona fortuna.

Dovresti impegnarti spesso. Dovresti sicuramente impegnarti dopo aver raggiunto qualche traguardo logico. Se ciò richiede più di un giorno, dovresti almeno impegnarti alla fine della tua giornata di lavoro, o, meglio ancora, suddividere il tuo lavoro in blocchi più piccoli.

Ci sono molte ragioni per farlo. Ad esempio, cosa succede se il tuo computer si blocca? È molto meglio perdere solo un giorno di lavoro di una settimana o di un mese. Un altro motivo è che frequenti commit rendono più facile isolare un bug. Puoi fare una ricerca binaria e capire quali piccole modifiche hanno causato il bug.

Un'altra cosa: prima di impegnarti, dovresti fare una differenza e osservare tutte le modifiche che hai apportato. Questo ti permette di controllare che tutte le modifiche abbiano un senso e che tu non abbia dimenticato nulla. Questo ti aiuta anche a trovare un messaggio di commit migliore. E, naturalmente, questo è un altro motivo per impegnarsi spesso: è molto più facile passare un giorno di cambiamenti oltre il valore di un mese.

Per ottenere il massimo da CVS, dovresti lavorare su una funzionalità / correzione di bug alla volta e impegnarti quando tale funzionalità / correzione di errori è completa. In questo modo otterrai:

• i messaggi di commit saranno più facili da creare e avranno più senso;
• più facile rintracciare i bug futuri alle modifiche che li hanno introdotti;
• più facile tornare a uno stato precedente (anche se questo significa perdere una funzione fallita ma mantenere correzioni di bug che si sono verificate in seguito).

Inoltre, dal momento che passi da un PC all'altro dovresti avere almeno due rami:

• un ramo "Ready to go" che funziona sempre (eccetto gli errori su cui stai lavorando nel ramo di sviluppo, ovviamente)
• un ramo di sviluppo che potrebbe trovarsi in uno stato irraggiungibile di tanto in tanto (come durante il tuo viaggio di ritorno a casa dal lavoro;).

Should each one-line change get a commit?

Se è questo che corregge un bug, certo.

What I am missing out on by having bad VCS habits?

Ho lavorato con un ragazzo che aveva "cattive abitudini VCS". Amava lavorare da solo e si occupava di una linea di prodotti che portava qualcosa come $ 1.000.000 all'anno. Avrebbe fatto solo dei patti quando il capo lo ha tormentato. Poi un giorno il suo disco rigido si è schiantato. Dopo aver ottenuto un set sostitutivo per lui, abbiamo scoperto che il suo ultimo check-in era 6 mesi prima. Dal momento che VCS era Source Safe, puoi indovinare cosa altro è andato storto: l'ultimo commit è stato danneggiato. Dovevamo tornare indietro più di un anno per ottenere una versione non danneggiata della sua linea di prodotti. Non è stato licenziato, anche se avrebbe dovuto essere.

Un altro aneddoto riguarda me stesso. Ho usato per memorizzare il codice per hobby e progetti di ricerca su hard disk rimovibili. Un giorno, il mio appartamento è stato rotto. Il laptop (che era rotto) e tutti i dischi rigidi rimovibili sono stati rubati. Ogni DVD (ad eccezione di Red Dawn) è stato rubato. Nessuno dei computer desktop è stato rubato. Se avessi il controllo del codice sorgente fuori sede, non avrei perso 15 anni di progetti, specialmente perché alcuni si basavano su progetti accademici - molti professionisti hanno abbandonato il mondo accademico per dedicarsi all'industria privata, quindi i progetti sono svaniti in un buco nero dell'IP aziendale. codice perso impossibile da recuperare.

How often should I be committing?

Scomposizione in poche metriche:

• Quanto lavoro sei disposto a perdere se il tuo computer muore? o viene rubato?

• Se corregge Bug_1234, controlla il codice con il commento "corregge Bug_1234".

• Se si tratta di una consegna / pietra miliare logica, verificarla con un commento come "Bug_1234, form_xyz" (o Task_1234, a seconda dei casi).

• Controlla sempre il codice venerdì sera prima di tornare a casa. Effettua anche il check-in (o disfa il checkout) di tutto prima di partire in vacanza.

• Ogni volta che la politica aziendale impone.

Non pensare in termini di numero di cambi di linee. Pensa a pezzi di funzionalità. VCS ti consente di dare un titolo in un punto centrale per ogni blocco di funzionalità in modo da poter vedere facilmente "cosa è successo qui" con ad es. git log.

Inoltre, IDE come Eclipse ti permettono di puntare a una determinata linea e andare al commit che lo ha portato nella forma che vedi. In altre parole, puoi andare direttamente da una linea di origine al commit. Se il commit è piccolo e ha un buon messaggio, è molto più utile di "fixed tons of bugs".

Direi che la cosa più grande che ti stai perdendo raggruppando le modifiche insieme è la possibilità di rintracciare quando e dove sono stati introdotti bug.

Nella mia esperienza, ci sono state un paio di volte in cui alcuni bug sono stati notati due-tre settimane dopo che è stato introdotto e dover setacciare il valore di una settimana di commit è difficile molto tempo dopo il fatto. In questi casi, è stato utile fare semplicemente una ricerca binaria attraverso i commit per rintracciare quale cambiamento individuale ha causato il problema. Questi bug erano per lo più errori di utilizzo della memoria sul codice C ++, quindi potrebbe non accadere così spesso per il tuo progetto.

Gli altri vantaggi entrano in gioco quando si sviluppa in una squadra: commenti di commit semplici, fusioni più semplici, commit di correzioni di errori, ecc.

Direi con il tuo flusso di lavoro che se inizi a impegnarti quotidianamente o parzialmente ogni giorno, dovrai utilizzare tag o segnalibri per tenere traccia di quale versione di codice è in uso sul sito live. Direi che è la cosa più importante da tenere sotto controllo.

Anch'io sono uno sviluppatore solista, uso SVN e lo adoro. Ho persino scritto uno strumento per convertire la struttura del mio database e i dati di test in esso in xml in modo che possa includerlo nel controllo del codice sorgente.

Di solito mi impegno ogni volta che ho completato un'unità di lavoro autonoma. A volte, se eseguo una serie di correzioni a riga singola banali e non correlate qua e là, li impegno tutti insieme, ma se una correzione a linea singola avviene tra due grandi unità di lavoro autonome non correlate, allora ottiene il suo commetti, non c'è niente di sbagliato in questo.

Inoltre, faccio sempre il commit del codice che compila, e quasi sempre il codice che passa anche tutti i test di base. In caso contrario, mi assicuro di includere "NON FUNZIONA" nel messaggio di commit. L'unico caso in cui questo accade è quando ho fatto cambiamenti importanti che non voglio perdere anche se non funzionano ancora, e per di più sto per imbarcarmi in una grande avventura di refactoring che non sono sicuro se avrà successo Quindi, io uso il repository come backup del lavoro che ho fatto finora prima di rischiare di rovinarlo e buttarlo via.

Ciò significa che mi impegno sempre quando è necessario eseguire il commit del codice sorgente; non ha assolutamente senso avere regole del commit del mattino o del commit della sera. È lo stato in cui è impostato il codice che determina se è o meno il momento di eseguire il commit.

I messaggi che hai inserito nel repository non contano molto. Se non riesci assolutamente a trovare qualcosa di significativo, è comunque meglio impegnarsi con un messaggio vuoto piuttosto che non impegnarsi affatto quando è necessario.

Se non riesci a pensare a un buon messaggio di commit perché tutto ciò che ti viene in mente sembra stupido, tieni presente che va bene così; i messaggi di commit dovrebbero dichiarare l'ovvio, quindi sono destinati a sembrare stupidi per te quando li stai scrivendo. Ma credimi, se hai bisogno di esaminare le vecchie revisioni un mese dopo sarai grato anche per i messaggi stupidi su nessun messaggio.

Impegna ogni volta che fai una modifica "logica". Ad esempio, se stai implementando una nuova funzione, lo stai facendo passo dopo passo. Ognuno di questi passaggi di solito dipende l'uno dall'altro. Quindi puoi semplicemente eseguire questi passaggi separatamente e spiegare nel messaggio di commit perché ogni passaggio è richiesto.

Il messaggio di commit è davvero importante. Devi evitare di dire a cosa stai facendo , dire a perché lo stai facendo. Il codice già documenta le modifiche, ma in 6 mesi sarai felice di vedere perché le hai eseguite.

Questo è utile anche se per caso qualcuno salta dentro e non sei più solo. Anche solo per te, una cronologia pulita semplifica l'utilizzo di git blame per sapere quando e perché quella riga che ha un bug è stata modificata.

Effettuare piccoli commit invece delle modifiche big ball of mud consente anche di testare lo stato intermedio. È possibile memorizzare le modifiche se è necessario rilasciare qualcosa con urgenza. Se introduci un bug mentre funzionava prima, puoi nascondere e verificare se sono le tue modifiche senza commit che introducono il bug, o se era in un commit precedente.

Puoi anche liberare la potenza di git bissect che ti dirà che commetti questo brutto bug. Se il commit è lungo 2.000 linee, aiuta ancora ma non così tanto ...

Un'altra cosa è che è il primo passo per l'integrazione continua (CI) e quindi la distribuzione continua (CD). CI e i tuoi test possono essere attivati su un nuovo commit, quindi ti dicono ogni volta che apporti le modifiche se rompono qualcosa o no. In questo modo puoi sapere se è possibile distribuirlo o meno e ricevere una notifica al momento dell'introduzione del problema e non solo prima del rilascio quando sei di fretta.

Informazioni sulle altre tue domande:

• non eseguire il commit di cose che non hai nemmeno compilato, a meno che tu non voglia riscrivere la tua cronologia per quello (usando git rebase --interactive ).
• un cambio di una riga merita un commit se ha uno scopo separato (corregge un bug o non è correlato alle modifiche attualmente non trasmesse). Usa git add --patch per metterli in scena.
• non è necessario forzare te stesso a impegnarsi prima di cena, a meno che tu non abbia cose importanti che non puoi permetterti di perdere. In tal caso, potresti voler impegnare in un ramo separato il tuo lavoro in corso.
• il commit e il push su un repository remoto è un backup. Se esegui il commit e spinga solo una volta alla settimana, puoi nel peggiore dei casi perdere una settimana di lavoro.

How often should I be committing?

Come sviluppatore solista, in genere mi impegno quando sento di aver apportato un cambiamento significativo, dopo i test di base, e quando lascio un progetto alla fine della serata.

Should each one-line change get a commit?

No, a meno che la modifica di una sola riga cambi significativamente una funzionalità o un bug.

Should I commit before any test (e.g., at least for syntax/compiling errors and then have to totally undo it; as the idea didn't work or the message is a lie)?

Probabilmente no. Almeno per me, faccio la maggior parte dei miei test e della codifica su una "copia di lavoro" e mi impegno dopo che sono soddisfatto dei miei cambiamenti. In molti IDE mi mostrerà ciò che è cambiato prima di eseguire effettivamente il commit e mi dà l'opportunità di allegare note al commit

Should I make sure I commit each morning/afternoon before I stop working for dinner while its still fresh? What I am missing out on by having bad VCS habits?

Non ho molta familiarità con VCS o quali cattive abitudini causano. Penso di aver condiviso per lo più la mia opinione su questo in risposta alla prima domanda.

In risposta alla domanda generale postulata, sembra che tu stia utilizzando principalmente i commit come rami che sono indirizzati in un altro post di responder. Non sono sicuro di quale IDE stai utilizzando che abbia una buona cronologia di annullamento, ecc., Ma non ne ho trovato uno che ritenessi soddisfacente al di là del riavvio dell'IDE e del passaggio tra le macchine.

Sono un committer abituale e ho trovato che mi va bene, ma devo ammettere 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 esattamente che fare un commit così frequente e abituale alla mia filiale (mercuriale) abbia esattamente incoraggiato i registri di commit più dettagliati. A volte eseguo addirittura il commit del codice a metà se, ad esempio, mia moglie mi chiede di uscire per cena, a quel punto copierò in tutta fretta e utilizzerò il messaggio di commit "Working on [...]" precedente.

I miei schemi di log di commit sono in genere, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

Il rovescio della medaglia però mi ha salvato il sedere. A volte mi imbatto in un caso limite che non ho previsto e non ho potuto testare, a quel punto i frequenti commit mi aiutano a capire esattamente dove ho introdotto l'errore.

Quindi non conosco le migliori abitudini e certamente non sono in grado di ascoltare le abitudini di registrazione dei commit ideali, ma posso certamente dire che l'impegno più frequente può sicuramente aiutare quando è necessario eseguire un regressione.

Should each one-line change get a commit?

Ho già effettuato modifiche su una sola riga, ma di solito sono complicate e forse ho avuto poco tempo. I miei impegni non sempre assomigliano a unità di lavoro o cambiamenti perfetti e completi. Come detto, a volte sono solo il risultato di mia moglie che mi chiede di andare fuori a cena inaspettatamente.

TBH molti dei miei commit che seguono che il pattern di "Working on [...]" log non sta modellando unità coerenti di cambiamento (perché spesso non riesco a trovare un messaggio migliore di "Working on [...]" ) ma solo il risultato di me che riprendo fiato, Mi piace farmi una tazza di caffè. Il messaggio "Completed [...]" indica la fine di quell'unità di lavoro, e lì scrivo spesso un messaggio molto più dettagliato insieme ai primi messaggi di tipo "Started working on [...]" quando inizio a lavorare su qualcosa. Se la media si impegna come una volta ogni 15 minuti, allora i messaggi "Lavorare su [...]" sono più simili all'intervallo per ciò che qualcuno potrebbe commettere in un ingombrante commit con un messaggio più dettagliato.

Should I commit before any test (e.g., at least for syntax/compiling errors and then have to totally undo it; as the idea didn't work or the message is a lie)?

Vado avanti e lo commetto prima ancora di eseguire i test a volte (di nuovo se avessi un evento inaspettato). Inoltre, anche se sono solo, spingo su un server (uno solo che gira qui a casa su una LAN) che fa CI. Potrebbe sembrare eccessivo, ma non so, mi sono così abituato ad appoggiarlo nei miei ex luoghi di lavoro. Inoltre non voglio essere preoccupato di dover eseguire tutte le mie unità e test di integrazione a mano ogni volta. Mi piace avere tutto legato solo alla spinta. Se un test fallisce è abbastanza facile lavorare in un modo in avanti in cui eseguo la regressione, correggere l'errore nell'ultimo rev e continuare ad andare avanti. Detto questo, faccio almeno build il codice contro una build di debug prima che io commetta.

Should I make sure I commit each morning/afternoon before I stop working for dinner while its still fresh?

Mi piace commettere prima di uscire e fare una pausa tra la programmazione. Non ho davvero pensato molto al motivo preciso fino a quando non ho incontrato questa domanda. Suppongo che sia per impedire a me stesso di riprendere da dove ho lasciato senza un registro di commit lì al posto di dove ho lasciato fuori che posso diff e così via. Hmm, ho bisogno di risponderti su questo dato che forse non è teoricamente necessario dato quanto frequentemente mi impegno. Mi sento ancora più a mio agio a commettere e spingere prima di lasciare il computer per qualsiasi motivo. Alcuni potrebbero essere l'ex paura psicologica di, diciamo, il computer che prende fuoco dopo che me ne vado e di avere i project manager nei giorni in cui stavamo usando SVN con gli sviluppatori a volte andando avanti per settimane senza commettere il respiro sul collo e ricordando costantemente dobbiamo controllare il codice il più spesso possibile ricordandoci che il nostro codice è di proprietà dell'azienda. Inoltre è un po 'più efficiente, specialmente con la spinta, in modo che il mio processo CI possa iniziare a eseguire tutti i test mentre sono via, così posso tornare e vedere i risultati.

Oh, a volte mi ubriaco un po 'dopo che me ne vado e di solito è una cattiva idea cercare di scrivere codice complesso mentre sono ubriaco (anche se non sempre, una volta mi è venuto in mente un bel menu di menu contestuale dopo un momento di eureka mentre ero ubriaco, ma avevo solo 6 birre e non era così complesso 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 leggere come, "Reverting back to code written before Jagermeister shots." I don ' Lo faccio molto spesso a meno che non mi sia venuta l'ispirazione per il codice ubriaco, ma in quei rari casi, è stato davvero d'aiuto che ho commesso qualcosa prima che uscissi e mi fossi ubriacato.