Perché si dovrebbero commettere modifiche al controllo della versione ogni tre minuti?

A seconda della quantità di storia che riscrive il processo di qualcuno, non è sempre possibile sapere come sono stati effettivamente cronometrati i commit in un DVCS. Il tuo progetto di esempio collegato utilizza MOE , che è un modo automatico per mantenere un progetto come una combinazione di aperto e chiuso fonte. Le raffiche di commit derivano probabilmente dall'uso di tale strumento automatico per strofinare i commit interni per renderli pubblici.

Un altro motivo per modelli di commit insoliti potrebbe essere un manutentore che applica una serie di patch via email o qualcosa del genere.

Di tanto in tanto ho commesso molto da vicino quando sto facendo qualcosa di relativamente meccanico, come la correzione di un mucchio di problemi di copertura. Ho sentito di praticanti del TDD fare un commit tra ogni ciclo di rosso / verde / refactoring. Ho sentito parlare di paranoici che impostano i commit automatici come una specie di salvataggio automatico. Sono sicuro che ci sono altri motivi per cui non sono a conoscenza.

La frequenza di spingere è completamente diversa. La regola è che dovresti essere sicuro che non causerà problemi alle altre persone. Non penso che potresti essere ragionevolmente sicuro di tre minuti tra una spinta e l'altra.

Una teoria potrebbe essere che ogni commit rappresenta un punto di rollback e quindi ogni commit consiste nell'avere una copia di questa versione della base di codice da qualche parte in modo che possa essere recuperata se lo si desidera. Questo è un po 'un breve ciclo di test poiché entrambe le modifiche e alcuni test iniziali verrebbero eseguiti prima di eseguire il commit.

Il pericolo qui è che se il luogo in cui questi commit vengono presi come codice base "pronto per la produzione", le cose potrebbero essere un problema.

D'altra parte, si potrebbe avere un gruppo di funzionalità finite che devono essere unite separatamente e quindi questa è l'unione di ciascuna funzionalità in modo che il commit sia più una fusione delle modifiche da qualche altra parte piuttosto che un nuovo sviluppo o test .

Quando inizi a pensare a commit come loro caratteristica individuale , o forse anche di più nel caso di un'alta frequenza, uno stato del progetto , non "salva" o "punti di rollback" , potresti spesso perdere questa frequenza di commit durante lo sviluppo normale, specialmente all'inizio di un progetto.

Mentre immagino che un commit ogni tre minuti sia piuttosto alto, a volte mi ritrovo a commettere ogni dieci minuti circa mentre analizzo mentalmente quella che potrebbe essere una singola funzione in piccoli pezzi / changeset.

Spero davvero di non vedere una "raccomandazione" in arrivo che più frequenti sono i commit, meglio è.

A mio parere, ogni commit dovrebbe lasciare il codice base il più possibile privo di bug, quindi i commit frequenti non sono una buona cosa se i bug (cioè le funzionalità incomplete) vengono consapevolmente inseriti nella base del codice. Inoltre, penso che ogni commit dovrebbe idealmente rappresentare una funzione aggiunta (modificata, rimossa), in modo che la funzionalità possa essere ripristinata annullando una singola lista di modifiche, senza allo stesso tempo annullare altre funzionalità che potrebbero essere desiderate. In questo modo si sostiene che il commit non sia troppo raro .

Certo, mi atteno a questo? Beh, ci provo, ma se qualche volta non ci riesco, non è motivo di licenziamento :) Spero.

Devi assicurarti che il tuo codice possa essere compilato e eseguito correttamente prima di firmare il codice. In caso contrario il lavoro dei tuoi colleghi verrà interrotto da te!    Penso che qualcuno commetta molto frequentemente non sia così buono.    Dovresti eseguire il commit dopo aver terminato e testato una funzione.    Dovresti impegnarti almeno una volta al giorno.