(1) Ben Collins-Sussman : "..." bombe a codice ". Cioè, cosa fai quando qualcuno si presenta a un progetto open source con una nuova gigantesca funzionalità che impiega mesi a scrivere? Chi ha il tempo di rivedere migliaia di righe di codice? ...

(2) Dan Fabulich : " The Code Bomb, o: The Newbie with Big Ideas ... Una bomba del codice è una patch talmente grande che nessuno può esaminarla.

(3) Google Summer of Code: Linee guida : "Impegnati presto, commetti spesso ... Per favore, non lavorare tutto il giorno e poi spingere tutto in una sola bomba del codice . Invece, ogni commit dovrebbe essere autonomo a un solo compito che dovrebbe essere riassunto nel messaggio del registro. "

(4) Jeff Atwood : "codice-bombe ... Regola n. 30: non diventa buio . ...

Probabilmente lo chiamiamo commit errato . :)

Cattiva pratica

E sì, questo sarebbe generalmente considerato una cattiva pratica , in quanto ha gli effetti negativi di:

• rendendolo difficile da recensire ,
• rendendolo difficile da cogliere facilmente e rapidamente l'intento originale del commit ,
• rendendolo difficile vedere come ha influito sul codice per risolvere o risolvere esplicitamente un problema ,
• rendendolo difficile sapere se la dimensione del commit è dovuta al rumore di altre modifiche eventualmente non correlate o non (ad esempio piccole pulizie o altri compiti).

Casi accettabili

Tuttavia, puoi avere casi in cui i grandi commit sono perfettamente accettabili . Ad esempio:

• quando si unisce ai rami ,
• quando aggiungi nuove fonti da un altro codebase non versione,
• quando sostituisce una funzione di grandi dimensioni sul posto (anche se dovresti farlo in un ramo, con commit più piccoli che affrontano diverse parti della modifica, quindi unire di nuovo l'intero elemento, quindi puoi avere una finestra migliore sullo sviluppo incrementale della funzione e sui problemi che potrebbero essersi incontrati lungo il percorso),
• quando refactoring un'API ha un impatto su molte classi discendenti e consumer.

Quindi, quando possibile, preferisci tipi di commit "chirurgici" (e collegali agli ID delle attività nel tuo tracker dei problemi!). Se hai una ragione valida, vai avanti.

A parte questo, in realtà non lo so e non penso di aver mai sentito un nome speciale per un grosso impegno. Un monster-commit? Un fat-commit?

Aggiornamento: David Cary's risponde a link a noti attori IT utilizzando il termine < strong> "code-bomb" (in particolare Collins-Sussman, creatore originale di Subversion ). Mi piace (anche se finora non posso dire di averlo sentito se spesso).

BTW, is committing a lot of changes all together a good practice?

Beh, non è una buona pratica tenere i cambiamenti a lungo, e implementare una varietà di funzionalità e correzioni di bug, e poi eseguirli, il che è un modo in cui un grosso commit potrebbe accadere.

Un altro modo in cui ciò potrebbe accadere è se un refactoring modifica la firma di una funzione ampiamente utilizzata, e quindi tutti quelli che devono essere modificati. Questo non è necessariamente cattivo, e non vorrei che gli sviluppatori si astenessero dal ripulire il codice per timore di attraversare qualche soglia.

Quindi, c'è dell'altro rispetto al solo numero di file toccati in un commit.

Il termine che ho ascoltato è "chunky check-in" . E io non sono un loro fan. Mi piacciono i piccoli commit che assicurano che nient'altro si rompa a un passo ragionevole in un progetto. Il grande impegno è generalmente carico di problemi che si riverberano per un po 'di tempo quando ciò accade.

Lo chiamo "tipico SVN commit" o "domani è il giorno di rilascio commit"

Per quanto io ami SVN, sono semplicemente escluso dal fatto che non posso eseguire commit locali.

EDIT: di solito contengono le parole "stuff" e "beer" nel messaggio di commit.

MODIFICA DI NUOVO: L'invio di molti cambiamenti, sebbene non necessariamente una cattiva pratica, dovrebbe essere evitato il più possibile. Trovo più facile rivedere una revisione / commit breve e concisa. (abbinato a un messaggio di commit ben scritto, vedi la mia modifica precedente per un cattivo esempio)

Un "grumo caldo di codice". : -)

• commit iniziale : il progetto che non era sottoposto al controllo di revisione è stato inserito in SVN
• refactoring - l'architetto ha una brillante idea di cambiare i nomi delle classi da / a Smurf Naming Convention o modificato la radice della gerarchia dei pacchetti
• formato di codice - l'architetto ha deciso di modificare il rientro del codice da 4 a 3 spazi o di modificare le terminazioni di linea da Unix a Windows (o ripristinare)
• Venerdì impegno - Joe è sempre impegnato per tutta la settimana a lavorare il venerdì alle 16:30
• uuups commit - Ted ha cancellato per errore la directory root, l'ha commesso, e ora pompa ancora una volta l'intera gerarchia di file in SVN

Di solito molte persone tendono a fare grandi commit usando VCS centralizzato, in particolare il server applica una buona politica di commit. Questo è il commit deve superare tutti i test e le prove richiedono più tempo (più di qualche secondo). Quindi gli sviluppatori non vogliono aspettare così tanto tempo per impegnarsi più volte e suddividere le modifiche in più piccoli commit.

E gli sviluppatori che sono verdi a VCS possono dimenticare di suddividere le modifiche in più piccoli commit. Ricordano solo di impegnarsi quando rilasciano il programma al team di QA. Peggio ancora, per evitare che altri vedessero codice buggato, non si impegnano prima di aver superato con successo il test del QA. Infine, non si sono resi conto che hanno impegnato binari di output, file temporanei e output di linker, che producono davvero commit "grande".