Con quale frequenza eseguire il commit delle modifiche al controllo del codice sorgente? [chiuso]

Con quale frequenza devo eseguire il commit delle modifiche al controllo del codice sorgente? Dopo ogni piccola funzionalità o solo per funzionalità di grandi dimensioni?

Sto lavorando a un progetto e ho una funzionalità a lungo termine da implementare. Attualmente, mi impegno dopo ogni pezzo di lavoro, ovvero ogni sub-funzionalità implementata e bug risolto. Mi impegno anche dopo aver aggiunto una nuova serie di test per alcune funzionalità dopo aver scoperto un bug.

Tuttavia, sono preoccupato per questo schema. In una giornata produttiva di lavoro potrei fare 10 impegni. Dato che sto usando Subversion, questi commit influiscono sull'intero repository, quindi mi chiedo se sia davvero una buona pratica farne così tanti?

Ogni volta che compio un "pensiero completo" sul codice che compila ed esegue faccio il check-in. Questo di solito finisce tra i 15-60 minuti. A volte potrebbe essere più lungo, ma cerco sempre di verificare se ho molte modifiche al codice che non vorrei riscrivere in caso di errore. Di solito mi assicuro anche che il mio codice venga compilato e faccio il check-in alla fine della giornata lavorativa prima di tornare a casa.

Non mi preoccuperei di fare "troppi" commit / check-in. Fa davvero schifo quando devi riscrivere qualcosa, ed è bello poter tornare indietro con piccoli incrementi per ogni evenienza.

Quando dici di essere preoccupato che i tuoi "commit incidano sull'intero repository" --- ti riferisci al fatto che il numero di revisione dell'intero repository aumenta? Non so quanti bit Subversion usa per memorizzarlo, ma sono abbastanza sicuro che non finirai i numeri di revisione! Molti commit non sono un problema. Puoi impegnarti dieci volte più spesso del ragazzo della porta accanto e non aumenterai affatto la tua impronta di carbonio.

Una singola funzione o metodo dovrebbe essere nominato per quello che fa, e se il nome è troppo lungo, sta facendo troppo. Cerco di applicare la stessa regola ai check-in: il commento del check-in dovrebbe descrivere esattamente ciò che la modifica realizza e, se il commento è troppo lungo, probabilmente sto cambiando troppo in una volta.

Mi piace questo piccolo articolo di Jeff Atwood: Check In Early, Check In Spesso

Personalmente commetto ogni gruppo logico di codice che è finito / stabile / compila e provo a non lasciare la giornata senza impegnarmi per quello che ho fatto quel giorno.

Se si stanno apportando modifiche importanti e si è preoccupati di influire sugli altri che lavorano sul codice, è possibile creare un nuovo ramo e quindi ricollegarlo nel trunk al termine delle modifiche.

Mi impegno ogni volta che ho finito un compito. Di solito ci vogliono da 30 minuti a 1 ora.

Se il commento sul controllo della versione è più lungo di una o due frasi, probabilmente non ti impegni abbastanza spesso.

Seguo il mantra open source (parafrasato) - commetto presto, commetto spesso.

Fondamentalmente ogni volta che penso di aver aggiunto funzionalità utili (per quanto piccole) senza introdurre problemi per gli altri membri del team.

Questa strategia di commit-spesso è particolarmente utile in ambienti di integrazione continua in quanto consente test di integrazione contro altri sforzi di sviluppo, fornendo una diagnosi precoce dei problemi.

Non eseguire il commit del codice che in realtà non funziona. Non utilizzare il repository come soluzione di backup.

Al contrario, esegui il backup locale del codice incompleto in modo automatico. Time Machine si prende cura di me e ci sono molti programmi gratuiti per altre piattaforme.

La regola empirica, che utilizzo, è il check-in quando il gruppo di file da archiviare può essere coperto da un singolo commento del check-in.

Questo generalmente assicura che i check-in siano atomici e che i commenti possano essere facilmente digeriti da altri sviluppatori.

È particolarmente vero quando le modifiche influiscono su un file di configurazione (come un file di contesto di primavera o un file di configurazione struts) che ha un ampio ambito di applicazione. Se si apportano diversi "gruppi" di modifiche prima del check-in, il loro impatto si sovrappone al file di configurazione, causando l'unione dei 2 gruppi.

Non penso che dovresti preoccuparti così tanto di quanto spesso. La cosa importante qui è cosa, quando e perché. Dire che devi impegnarti ogni 3 ore o ogni 24 ore non ha davvero senso. Impegnati quando hai qualcosa da impegnare, non farlo se non lo fai.

Ecco un estratto delle mie migliori pratiche consigliate per il controllo della versione :

[...] Se stai apportando molte modifiche a un progetto contemporaneamente, suddividile in parti logiche e impegnale in più sessioni. Questo rende molto più semplice tenere traccia della cronologia delle singole modifiche, il che ti farà risparmiare molto tempo quando cerchi di trovare e correggere i bug in seguito. Ad esempio, se si implementano le funzionalità A, B e C e si correggono i bug 1, 2 e 3, ciò dovrebbe comportare un totale di almeno sei commit, uno per ogni funzione e uno per ogni bug. Se stai lavorando a una grande funzionalità o stai eseguendo un ampio refactoring, considera di dividere il tuo lavoro in parti ancora più piccole e fai un commit dopo che ogni parte è stata completata. Inoltre, quando si implementano modifiche indipendenti su più moduli logici, eseguire le modifiche su ciascun modulo separatamente, anche se fanno parte di una modifica più grande.

Idealmente, non dovresti mai lasciare il tuo ufficio con modifiche senza impegno sul tuo disco rigido. Se stai lavorando a progetti in cui le modifiche influiranno su altre persone, considera di utilizzare un ramo per implementare le modifiche e fonderle nuovamente nel trunk al termine. Quando si effettuano modifiche a librerie o progetti da cui dipendono altri progetti, e quindi altre persone, assicurarsi di non interrompere le loro build impegnando codice che non verrà compilato. Tuttavia, avere un codice che non viene compilato non è una scusa per evitare di impegnarsi. Usa invece i rami. [...]

Il tuo modello attuale ha senso. Tieni presente come usi questo controllo del codice sorgente: cosa succede se devi eseguire il rollback o se vuoi fare un diff? I blocchi che descrivi sembrano esattamente il differenziale giusto in quei casi: il diff ti mostrerà esattamente cosa è cambiato nell'implementazione del bug # (specificato nel registro del checkin), o esattamente quale fosse il nuovo codice per l'implementazione di una funzione. Il rollback, allo stesso modo, toccherà solo una cosa alla volta.

Mi piace anche impegnarmi dopo aver finito un pezzo di lavoro, che spesso è più volte al giorno. Penso che sia più facile vedere cosa sta succedendo nei piccoli impegni rispetto a quelli grandi. Se sei preoccupato per troppi commit, potresti prendere in considerazione la creazione di un ramo e la fusione di nuovo nel trunk al termine dell'intera funzione.

Ecco un post sul blog correlato: Coding Horror: Check In Early, Check In Spesso

Come altri hanno già affermato, prova a eseguire il commit di un blocco logico sufficientemente "completo" da non ostacolare gli altri sviluppatori (ad esempio, crea e supera test automatici).

Ogni team / azienda di sviluppo deve definire ciò che è "abbastanza completo" per ogni filiale. Ad esempio, potresti avere rami di funzionalità che richiedono solo la compilazione del codice, un Trunk che richiede anche il codice per superare i test automatizzati ed etichette che indicano che qualcosa ha superato il test QA ... o qualcosa del genere.

Non sto dicendo che questo è un buon modello da seguire; Sto solo sottolineando che il modo in cui si fa "dipende" dipende dalle politiche del proprio team / azienda.

Nel momento in cui ci pensi.

(purché ciò che fai il check-in sia sicuro)

Dipende dal sistema di codice sorgente e da cos'altro hai in atto. Se stai usando Git, esegui il commit ogni volta che finisci un passaggio. Uso SVN e mi piace impegnarmi quando finisco un'intera funzione, quindi da una a cinque ore. Se stessi usando CVS farei lo stesso.

Sono d'accordo con diverse risposte: non controllare il codice che non verrà compilato; utilizzare una filiale o un repository personale se il problema riguarda un "backup" del codice o delle sue modifiche; verificare quando le unità logiche sono complete.

Un'altra cosa che aggiungerei è che a seconda del tuo ambiente, la tariffa del check-in può variare nel tempo. Ad esempio, all'inizio di un progetto il check-in dopo che ogni pezzo funzionale di un componente è completo ha senso sia per la sicurezza che per una cronologia delle revisioni (sto pensando ai casi in cui i bit precedenti vengono refactored mentre quelli successivi vengono sviluppati). Più avanti nel progetto, d'altra parte, la funzionalità completamente completa diventa più importante, specialmente durante lo sviluppo / test dell'integrazione. Una mezza integrazione o una mezza correzione non aiuta nessuno.

Per quanto riguarda il check-in dopo ogni correzione di bug: a meno che la correzione non sia banale, assolutamente! Niente è più di una seccatura che scoprire che un check-in conteneva tre correzioni e una di esse deve essere ripristinata. Il più delle volte sembra che in quella situazione lo sviluppatore abbia risolto tre bug in un'area e scoprendo quale cambiamento va a quale correzione di bug è un incubo.

Mi piace anche fare il check-in regolarmente. Cioè ogni volta che compio un passo verso il mio obiettivo.

Questo è in genere ogni paio d'ore .

La mia difficoltà è trovare qualcuno disposto e in grado di eseguire così tante revisioni del codice .

La nostra politica aziendale è che abbiamo bisogno di avere una revisione del codice prima di poter fare il check in, il che ha senso, ma non c'è sempre qualcuno nel dipartimento che abbia il tempo di eseguire immediatamente una revisione del codice. Possibili soluzioni:

1. Più lavoro per check-in; meno check-in == meno recensioni.
2. Modifica la politica di registrazione dell'azienda. Se ho appena eseguito un refactoring e i test unitari sono tutti verdi, forse posso rilassare la regola?
3. Metti da parte il resto finché qualcuno non può eseguire la revisione e continuare a lavorare. Questo può essere problematico se al revisore non piace il tuo codice e devi riprogettarlo. Destreggiarsi tra le diverse fasi di un'attività "accantonando" i cambiamenti può diventare disordinato.

Mi piace apportare modifiche ogni 30-60 minuti, purché si compili in modo pulito e non vi siano regressioni nei test unitari.

Bene, potresti avere il tuo ramo a cui puoi impegnarti tutte le volte che vuoi e quando hai finito con la tua funzione, puoi unirlo al trunk principale.

Sulla frequenza di Commit, la penso in questo modo, quanto dolore sarebbe per me se il mio hard disk si schiantasse e non avessi commesso qualcosa - il quanto di questo qualcosa per me è di circa 2 ore di lavoro.

Certo, non commetto mai qualcosa che non viene compilato.

Almeno una volta al giorno.

Non ho un limite di tempo specifico per commit, tendo a impegnarmi una volta superato un test e sono soddisfatto del codice. Non commetterei codice che non viene compilato o che è altrimenti in uno stato in cui non mi sentirei bene a tornare in caso di errore

Devi bilanciare il compromesso tra sicurezza e recuperabilità da un lato e facilità di gestione delle modifiche per l'intero progetto dall'altro.

Lo schema migliore che ho usato ha avuto due risposte a quella domanda.

Abbiamo usato 2 repository completamente separati: uno era il repository a livello di progetto e l'altro era il nostro repository personale (all'epoca usavamo rcs).

Verificheremo nel nostro repository personale molto regolarmente, praticamente ogni volta che salvate i file aperti. In quanto tale, il repository personale era fondamentalmente un grosso buffer di annullamento a lungo raggio.

Una volta che avevamo un pezzo di codice che si sarebbe compilato, testato ok ed accettato come pronto per l'uso generale, è stato verificato nel repository del progetto.

Sfortunatamente questo sistema si basava sull'uso di diverse tecnologie VCS per essere praticabile. Non ho trovato alcun metodo soddisfacente per ottenere gli stessi risultati durante l'utilizzo di due VCS dello stesso tipo (ad es. Due repository di sovversione)

Tuttavia, ho avuto risultati accettabili creando rami di sviluppo "personali" in un repository di sovversione - controllando regolarmente il ramo e poi unendomi al tronco al completamento.

Se stai lavorando su un ramo che non verrà rilasciato, un commit è sempre sicuro.

Tuttavia, se lo condividi con altri sviluppatori, è probabile che commettere codice non funzionante sia un po 'fastidioso (soprattutto se si trova in un posto importante). Normalmente eseguo il commit solo del codice che "funziona" in modo efficace, non che sia stato testato completamente, ma che ho accertato che effettivamente si compila e non fallisce immediatamente.

Se stai utilizzando un tracker di bug integrato, può essere utile eseguire commit separati se hai corretto due bug, in modo che il registro di commit possa andare contro i bug giusti. Ma ancora una volta, a volte una modifica del codice risolve due bug, quindi devi solo scegliere a quale metterlo (a meno che il tuo sistema non consenta a un commit di essere associato a più bug)

Credo ancora nella frase "commetti spesso, commetti in anticipo". Preferisco VCS decentralizzato come Mercurial e non c'è problema a impegnare diverse cose e spingerlo a monte più tardi.

Questa è davvero una domanda comune, ma la vera domanda è: puoi commettere un codice incompleto?

Ogni volta che finisci un codice che funziona e non rovinerà nessun altro se lo ottiene in un aggiornamento.

E assicurati di commentare correttamente.