Quanto spesso dovrei / farmi commettere? [duplicare]

Ogni volta che ho qualcosa che funziona (cioè, non rompe nulla per nessun altro) farò un check-in. Prima scrivo la maggior parte dei miei test di roba, quindi ogni volta che passo un nuovo test, effettuo il check-in.

In pratica ciò significa poche volte all'ora. Almeno un paio di volte ogni ora, con 5 è un bel po '.

Non dovresti eseguire il commit in base al tempo, ma in base a una funzione. Ogni volta che aggiungi una nuova funzione che vale la pena commettere, commetti. Hai aggiunto un metodo di lavoro? Commettere. Hai corretto un refuso? Commettere. Hai corretto un rientro sbagliato di un file? Commettere. Non c'è nulla di sbagliato nell'impegnare piccole modifiche, non appena il commit è rilevante.

Ciò che è sbagliato è commettere un numero enorme di cambiamenti, senza relazioni tra di loro. Rende molto difficile rilevare l'origine del commit di una data regressione.

A volte, eseguo venti commit in un'ora e talvolta mi impegno una volta al giorno, a seconda della quantità di codice che è stata modificata.

Effettuare piccoli commit ti permette di usare strumenti molto potenti come git-bisect.

Non dimenticare la regola n ° 1 del committer: non spezzare mai il bagagliaio. Se hai bisogno di eseguire più commit che potrebbero rompere il tronco, crea invece un ramo.

Dipende un po 'da cosa è l'ambiente di sviluppo.

Se sei l'unico che contribuisce a una base di codice, allora un commit posticipato non sarà così cruciale. Tuttavia, se sei in un team di diversi sviluppatori e tutti pensano "oh, bene, aspetterò con il commit un po '", quindi spesso finirai per gestire molti conflitti e perdere molto tempo.

La regola generale (per entrambi gli scenari) sarebbe: Impegna il più spesso possibile. Se pensi che "non è ancora pronto" (perché spezzerà la build o semplicemente non è ancora finito) quindi crea un ramo e esegui il commit su quel ramo ma assicurati di farlo.

Almeno una volta al giorno, di solito tre o quattro, poiché tendo a impegnarmi ogni volta che faccio una pausa. Lavoro da solo, quindi non mi devo preoccupare di incasinare qualcun altro e posso sempre ripristinare un file se penso di aver sbagliato strada.

Ho avuto una brutta esperienza una volta quando non stavo facendo commit regolarmente e il mio disco rigido si è schiantato e ho perso alcune ore di lavoro. Poiché il mio repository si trova su un'altra macchina e viene eseguito regolarmente il backup, non c'è motivo per cui avrei dovuto perdere qualcosa.

Grazie ai rami git e al modo in cui sono gestiti facilmente, mi impegno molto spesso. Direi che ogni volta che aggiungi qualcosa che ritieni sia importante e ciò potrebbe aggiungere alla costruzione di qualcosa più tardi, dovresti impegnarti.

Inoltre, spesso mi trovo a fare alcuni refactoring e aggiungere nuovi test prima del nuovo codice, quindi per questo caso mi impegno per ogni volta che eseguo il test, lo guardo fallire, lo faccio passare di nuovo e refactoring.

Inoltre, dopo ogni correzione di bug non importa quanto piccolo o insignificante possa sembrare.

A volte vado giù per la strada "commit it non appena compila".

In DVCS, mi impegno praticamente ogni volta che inizio una modifica che sarebbe davvero noiosa se non potessi annullare, ogni volta che ho bisogno di condividerla con altri, o ogni volta sarebbe davvero utile vedere cosa ho cambiato da quando quel punto. Ciò varia da diverse volte all'ora a un paio di volte al giorno. Inoltre, commetto molto raramente quando la mia build non si limita a compilare ed eseguire senza segfault, ma può essere utile anche se vuoi essere in grado di isolare e condividere solo la correzione per quel particolare bug.

Nota con il controllo della versione centralizzata, che è molto probabile che ti venga richiesto di utilizzare sul lavoro, generalmente non ti impegni finché non sei abbastanza sicuro di non ricevere una tempesta di email arrabbiate per farlo. A seconda di quanto siano indipendenti le modifiche che stai apportando e quanto la tua azienda sottoscriva il dogma dell'integrazione continua, è più simile a una volta al giorno, forse una volta al mese, su una grande novità.

La differenza di frequenza è uno dei motivi principali per cui uso git sopra il VCS centralizzato ufficiale della mia azienda.

Se lavori in un ambiente di team con un server di build, ti basterà impegnare solo quando hai qualcosa che si costruisce. Altrimenti è molto fastidioso per il resto della squadra:)

Ho guardato questa presentazione Joel On Software - FogBugz / Kiln di recente e penso che si riferisca bene a la tua domanda.

Mentre in alcune versioni il controllo 'commit' è sinonimo di 'publish' (o 'dà dolore agli altri') nei VCS distribuiti, sono spesso separati.

Quindi quando il commit può dipendere dal VCS che usi.

Effettua il commit automatico dopo ogni build completata.

Suppongo che, se si desidera ripristinare una versione precedente, e si ricordi il tempo approssimativo di wall-wall del punto in cui si desidera tornare, è sufficiente consultare la revisione.

Naturalmente se usi TDD ci sono soluzioni integrate migliori.

Ogni sera quando torno a casa ho una sceneggiatura che passerà automaticamente in tutte le mie filiali e fare un commit (nota che tutti gli sviluppatori non ottengono questi cambiamenti, è solo una mia filiale personale). In questo modo non devo pensarci.

Inoltre ho uno script che eseguirà automaticamente un aggiornamento al mattino. Io uso questo in modo che se lavoro dal mio portatile di notte le mie modifiche sono automaticamente lì al mattino.

Per quanto riguarda il rollback delle modifiche apportate durante il giorno, il mio editor ha una cronologia di tutte le modifiche ed è molto più veloce di un commit su ogni salvataggio / compilazione.

Lavoro da solo. Il mio ambiente di sviluppo è il mio taccuino. L'ambiente di commit è un server sul Web.

Se il client utilizza il server Web per tenere traccia dei progressi. Così quasi ogni giorno faccio un upload insieme a una e-mail che dice cosa c'è di nuovo.

Se l'ambiente di commit è un ambiente di produzione, devo essere più attento a ogni modifica in fase di test prima di qualsiasi commit. Tuttavia, spesso sembra migliore, poiché nessuno ha dubbi sul fatto che la nuova funzionalità sia già stata pianificata o già eseguita; ottengono quello che chiedono il più presto possibile.