A volte quando controlliamo la cronologia dei commit di un software, potremmo vedere che ci sono alcuni commit che sono davvero GRANDI - possono cambiare 10 o 20 file con centinaia di righe di codice sorgente modificate (delta). Ricordo che esiste un termine comunemente usato per tale GRANDE commit, ma non ricordo esattamente quale sia quel termine. Qualcuno può aiutarmi? Qual è il termine che i programmatori usano di solito per riferirsi a tali GRANDI e commit giganti?

A proposito, commettere molti cambiamenti tutti insieme è una buona pratica?

AGGIORNAMENTO: grazie ragazzi per la discussione stimolante! Ma penso che "bomba di codice" sia il termine che sto cercando.

(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 recensire migliaia di righe di codice? ... "

(2) Dan Fabulich : "La bomba del codice, o: Il principiante con grandi idee ... A bomba del codice è una patch così 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 espellere tutto in un unico bomba di codice . Invece, ogni commit dovrebbe essere autonomo per un solo compito che dovrebbe essere riassunto nel messaggio di registro. "

(4) Jeff Atwood : "bombe di codice ... Regola n. 30: non fare buio . ...

Probabilmente lo chiamiamo un cattivo commit . :)

Cattiva pratica

E sì, ciò sarebbe generalmente considerato una cattiva pratica , poiché ha gli effetti negativi di:

• rendendo difficile la revisione ,
• rendendo difficile comprendere facilmente e rapidamente l'intento originale del commit ,
• rendendo difficile vedere come ha influito sul codice per risolvere esplicitamente o risolvere un problema ,
• rendendo difficile sapere se le dimensioni del commit sono dovute al rumore di altre modifiche eventualmente non correlate (ad es. piccole pulizie o altre attività).

Casi accettabili

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

• quando si fondono tra i rami ,
• quando si aggiungono nuove fonti da un altro codebase senza versione,
• quando si sostituisce una funzionalità di grandi dimensioni sul posto (anche se è preferibile farlo in un ramo, con commit più piccoli che affrontano diverse parti della modifica e quindi uniscono nuovamente tutto, in modo da poter avere una finestra migliore sullo sviluppo incrementale del funzionalità e i problemi che potrebbero essere stati riscontrati lungo il percorso),
• durante il refactoring di un'API che influisce su molte classi discendenti e consumer.

Quindi, quando possibile, preferisci i tipi di commit "strike chirurgico" (e collegali agli ID attività nel tracker dei problemi!). Se hai un motivo valido, vai avanti.

A parte questo, in realtà non lo so e non credo di aver mai sentito un nome speciale per un grande commit. Un mostro commesso? Un impegno fatale?

Aggiornamento: la risposta di David Cary si collega a noti attori IT usando il termine "bomba a codice" (soprattutto, Collins-Sussman, creatore originale di Subversion ). Così (anche se finora non posso dire di aver sentito spesso).

A proposito, commettere molti cambiamenti tutti insieme è una buona pratica?

Bene, non è buona prassi tenere a lungo le modifiche e implementare una varietà di funzionalità e correzioni di bug, quindi impegnarle, il che è un modo in cui potrebbe verificarsi un grande commit.

Un altro modo in cui ciò potrebbe accadere è se un refactoring modifica la firma di una funzione ampiamente utilizzata e quindi tutte quelle devono essere cambiate. Questo non è necessariamente negativo, e non vorrei che gli sviluppatori si trattenessero dal ripulire il codice per paura di superare una soglia.

Quindi, c'è di più oltre al semplice guardare il numero di file toccati in un commit.

Il termine che ho sentito è "grosso check-in" . E non ne sono un fan. Mi piacciono i piccoli impegni che assicurano che nient'altro venga interrotto a un passo ragionevole in un progetto. Il grande impegno è generalmente irto di problemi che si riverberano per qualche tempo fuori da ciò che accade.

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

Per quanto adoro SVN, sono semplicemente disattivato dal fatto che non posso fare impegni locali.

EDIT: di solito hanno le parole "roba" e "birra" nel messaggio di commit.

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

Un "blocco di codice a vapore caldo". :-)

• commit iniziale : il progetto che non era sotto 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 ha cambiato la radice della gerarchia dei pacchetti
• formato del 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)
• Impegno del venerdì - Joe si impegna sempre per tutta la settimana 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 impegnarsi in modo massiccio utilizzando VCS centralizzato, in particolare il server applica una buona politica di commit. Questo è il commit deve superare tutti i test e i test impiegano 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 per VCS potrebbero dimenticare di suddividere le modifiche in più piccoli commit. Ricordano di impegnarsi solo quando rilasciano il programma al team QA. Peggio ancora, per evitare che altri vedano il codice errato, non si impegnano prima di aver superato con successo i test di controllo qualità. Infine, non si sono resi conto di aver eseguito il commit dei file binari di output, dei file temporanei e dell'output del linker, che producono effettivamente un commit "grande".