Quando un commit del controllo versione è troppo grande? [chiuso]

Ho sentito in diversi posti "Non fare grandi commit" ma non ho mai capito cosa sia un "grande" commit. È grande se lavori su un mucchio di file anche se correlati? A quante parti di un progetto dovresti lavorare contemporaneamente?

Per me, ho difficoltà a provare a fare "piccoli commit" poiché dimentico o creo qualcosa che crea qualcos'altro che crea qualcos'altro. Quindi si finisce con cose come questa:

Crea coda in uscita personalizzata

Bot
-Nuovo campo msgQueue che non è altro che un SingleThreadExecutor
-sendMsg si blocca fino all'invio del messaggio e aggiunge l'attesa tra quando i messaggi vengono ricevuti
inviato
-adminEsiste chiamate aggiornate (vedi controller)
-Rimosse chiamate a sendMessage

controllore
-Nuovo campo msgWait indica il tempo di attesa tra i messaggi
-L'avvio dei plug-in di servizio è stato spostato in ricaricare Plugin
-adminExists spostato dal server a causa degli amministratori globali. Controlli sul canale,
server e livello globale

Admin
-Nuovi metodi getServer e getChannel che ottengono l'oggetto appropriato Admin
appartiene a

BotEvent
-toString () mostra anche extra ed extra1

Canale
-channel field rinominato in name
-Resatto errore di battitura nel canale (int)

server
-Moved adminExists to Controller

PluginExecutor
-Minor testing aggiunto, verrà rimosso in seguito

Plugin JS
-Aggiornato alle modifiche al framework
-Sostituito InstanceTracker.getController () con Controller.instance
-VLC parla ora nel proprio file

Vari aggiornamenti e modifiche al progetto NB

---

File interessati
Modifica /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Modifica /trunk/Quackbot-Core/dist/README.TXT
Modifica /trunk/Quackbot-Core/nbproject/private/private.properties
Modifica /trunk/Quackbot-Core/nbproject/private/private.xml
Modifica /trunk/Quackbot-Core/src/Quackbot/Bot.java
Modifica /trunk/Quackbot-Core/src/Quackbot/Controller.java
Modifica /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Modifica /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Modifica /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Modifica /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Modifica /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Modifica /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Modifica /trunk/Quackbot-GUI/dist/README.TXT
Modifica /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Modifica /trunk/Quackbot-GUI/nbproject/private/private.properties
Modifica /trunk/Quackbot-GUI/nbproject/private/private.xml
Modifica /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Modifica /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Elimina /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Modifica /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Modifica /trunk/Quackbot-Impl/dist/README.TXT
Modifica /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Modifica /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Modifica /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Modifica /trunk/Quackbot-Impl/lib/javarebel.stats
Aggiungi /trunk/Quackbot-Impl/lib/jrebel.info
Modifica /trunk/Quackbot-Impl/nbproject/private/private.properties
Modifica /trunk/Quackbot-Impl/nbproject/private/private.xml
Modifica /trunk/Quackbot-Impl/nbproject/project.properties
Modifica /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Aggiungi / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
Modifica /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Modifica /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Modifica /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Modifica /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Modifica /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Modifica /trunk/Quackbot-Impl/plugins/testCase.js
Aggiungi /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Modifica /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Aggiungi / trunk / Quackbot-Impl / vlc_http
Aggiungi /trunk/Quackbot-Impl/vlc_http/current.html
Modifica /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Modifica /trunk/Quackbot-Plugins/dist/README.TXT
Modifica /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Modifica /trunk/Quackbot-Plugins/nbproject/private/private.properties
Modifica /trunk/Quackbot-Plugins/nbproject/private/private.xml
Modifica /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Aggiungi / trunk / Quackbot-Plugins / vlc_http
Aggiungi /trunk/global-lib/jrebel.jar

Sì....

Quindi per domande:

• Quali sono alcuni fattori per quando un commit diventa troppo grande ( cose non ovvie )?
• Come puoi impedire tali impegni? Si prega di fornire dettagli
• Che dire di quando sei nelle prime fasi di sviluppo quando le cose si muovono rapidamente? Gli enormi commit sono ancora a posto?

Per me, ho difficoltà a provare a fare "piccoli commit" poiché dimentico o creo qualcosa che crea qualcos'altro che crea qualcos'altro.

Questo è un problema Sembra che tu debba imparare a scomporre il tuo lavoro in blocchi più piccoli e più gestibili.

Il problema con commit di grandi dimensioni sono:

• In un progetto multi-persona, una maggiore possibilità che i tuoi impegni causino la risoluzione di conflitti per altri sviluppatori.
• È più difficile descrivere accuratamente ciò che è stato fatto nei messaggi di registro.
• È più difficile tenere traccia dell'ordine in cui sono state apportate le modifiche e quindi comprendere la causa dei problemi.
• Aumenta la probabilità di perdere molto lavoro senza impegno.

A volte sono inevitabili grandi commit; ad es. se devi modificare un'API principale. Ma questo non è normalmente il caso. E se ti trovi in ​​questa situazione, è probabilmente una buona idea creare una filiale e svolgere il tuo lavoro lì dentro ... con un sacco di piccoli impegni ... e reintegrare quando hai finito.

(Un altro caso è quando si esegue un'importazione iniziale, ma NON è un problema dal punto di vista dei problemi sopra elencati.)

Il principio di responsabilità unica.

Ogni commit del controllo del codice sorgente dovrebbe avere un solo scopo. Se devi inserire la parola "e" o "anche" nel tuo riepilogo, devi dividerla.

È molto comune finire con un sacco di modifiche separate non correlate o semi-correlate nella tua copia di lavoro. Questo è chiamato il "problema della copia funzionante aggrovigliata" ed è in realtà molto difficile da evitare anche per gli sviluppatori disciplinati. Tuttavia, Git e Mercurial offrono entrambi gli strumenti per risolverlo - rispettivamente git add -p o chunk selection e Mercurial Queues in TortoiseHg .

Immagina che il cliente abbia chiesto di apportare una modifica particolare, ad esempio per aggiungere una regola secondo la quale qualcosa o un altro non può essere fatto entro due giorni dalla data "qualunque". Quindi, dopo aver apportato la modifica, cambiano idea. Dovrai ripristinare il commit. Se è tutto sommato da alcune cose su come cambiare il tipo di rapporti non correlati, la tua vita è una sofferenza.

Un oggetto di lavoro, un changeset. Una richiesta dal client, un changeset. Una cosa su cui potresti farti cambiare idea, un changeset. A volte ciò significa che è una singola riga di codice. A volte sono dieci diversi file incluso lo schema del database. Va bene.

I grandi impegni si verificano quando hai tonnellate di modifiche che non vanno davvero tutte nello stesso secchio. Se cambio la logica del controller, quindi il modello di connessione al database, quindi qualche errore. script, non dovrei raggruppare tutto in un unico commit.

La prevenzione è impegnarsi in base a ciò che stai completando. Nell'esempio sopra commetterei dopo la logica del controller, dopo il funzionamento del database e dopo gli script. Non rimandare commettere semplicemente perché si sa che cosa è cambiato. Altre persone guarderanno indietro al tuo messaggio di registro "Cose cambiate" e si chiederanno cosa stavi fumando.

Le importazioni iniziali sono probabilmente i maggiori impegni che dovresti mai avere. Configurare un sistema da zero? Certo, ci sono alcuni grandi impegni. Dopo averlo livellato, è tempo di organizzare le cose.

Se sai che lavorerai su una grande porzione di codice in anticipo, ti suggerirei di creare un ramo per la tua caratteristica specifica mentre periodicamente tiri giù il codice dalla linea principale per assicurarti che il codice rimanga sincronizzato. Quando hai finito di lavorare sul ramo, unisci di nuovo tutte le modifiche alla linea principale. In questo modo gli altri membri del team non saranno sorpresi e / o infastiditi quando vedranno un grande impegno. Inoltre, ci sono molte meno possibilità di rompere le cose. Continua ad esercitarti per scomporre le cose in piccoli impegni. Con il tempo diventerà una seconda natura.

Questo esempio mostra un commit troppo grande.

Come regola empirica, descrivi il cambiamento in una frase o una riga di testo. (In base a questa regola, il commit dovrebbe essere suddiviso in 10-15 più piccoli.) Se non puoi commentare adeguatamente un commit in una riga, allora è già troppo grande.

Per esercitarti in piccoli commit, prendi appunti nel tuo blocco note (o nel Blocco note) di ciò che hai già modificato o aggiunto. Effettua il commit prima che diventi un lungo elenco o prima di apportare una modifica del codice non correlata a ciò che hai già nel blocco note.

Nel mio campo (modellazione fisica), ho scoperto un bug nell'output oggi che non era nel repository fino a 6 mesi fa. Quando ciò accade, eseguirò una ricerca binaria sulle revisioni:

1. Esegui il modello da 3 mesi fa
2. Se il bug è ancora in uscita, eseguire il modello da 4,5 mesi fa
3. ... ripeti finché non trovo il commit che produce un output errato

Quando il bug è stato introdotto in un commit mostruoso, devo sedermi con un pettine a denti fini per trovare l'origine del problema. Se il commit ha toccato un piccolo numero di file, è meno doloroso rintracciare le righe di codice che hanno introdotto il problema.

Consiglierei di suddividere il problema in una serie di attività più piccole (idealmente mettere ogni attività in un tracker di bug). Effettua un commit mentre completi ogni attività (e chiudi quel bug / funzionalità nel tuo bug tracker).

Non è la dimensione del commit che conta davvero, è la portata del cambiamento che dovrebbe determinare come sono organizzati i tuoi impegni.

Si potrebbe, ad esempio, cambiare ogni istanza di __macro1ad __macro2in una grande base di codice, che cambia 200 file. 200 impegni non sarebbero sani in quel caso.

Quello che vuoi finire è essere in grado di estrarre il repository ad ogni singola revisione e avere il lavoro di compilazione. Sei cambiato da libfooa libbar? Spero che il cambiamento includa anche l'aggiornamento degli script di build e dei Makefile (o di qualunque altra cosa sia applicabile).

A volte, potresti dover apportare una serie di modifiche sperimentali che realizzano una cosa, nel qual caso, devi determinare quale ambito è più importante per te se è necessario ripristinare in seguito. Uno dipende dall'altro? Impegnali tutti in una volta in un'unica revisione. Altrimenti, in tal caso, suggerirei un commit per modifica. Dovresti fare qualcosa del genere in un altro ramo o comunque in un altro repository.

Anche se sì, hai il potere di ripristinare un singolo file a una revisione precedente (eseguendo il backup di un file per un impegno più ampio), facendo così rovina strumenti come la dissezione più avanti lungo la strada e inquina la storia.

Se ti fermi e pensi "Ok, i test passano, penso che funzioni ... ma se va male, posso facilmente ripristinarlo?" .. finirai per prendere impegni sensati.

La cosa da capire qui è che "Grande" in questo contesto riguarda il numero di cambiamenti distinti e non la dimensione fisica del commit (anche se generalmente i due andranno di pari passo).

La sua non è quindi una questione di "non fare grandi commit" come fare fare piccoli commit - l'ideale è quello di impegnarsi piccolo autosufficiente modifiche.

È chiaro dal log delle modifiche che hai una serie di cose che avrebbero potuto essere commesse separatamente (e in modo sicuro) e quindi è abbastanza evidente che è troppo grande.

Il motivo per cui questo può essere un problema è che il tuo ultimo commit è il punto di riferimento per le modifiche che stai apportando e se, ad esempio, ottieni il primo bit giusto e poi sbagli il prossimo bit, non è facile per riportare il tuo lavoro al punto in cui hai iniziato a commettere errori (BTDTGTTS).

Ovviamente a volte i cambiamenti sono semplicemente grandi - refactoring su larga scala - e come suggerito da altri è qui che devi ramificare, in quel modo anche se il tuo individuo si impegna potrebbe rompere teoricamente le cose che sono separate dal tronco principale di sviluppo in modo che non sia un problema e continui a impegnarti presto e spesso.

Ancora una cosa: se nel mezzo del tuo lavoro arriva qualcosa che richiede un'attenzione più immediata, devi cambiarlo separatamente (idealmente in un set di cartelle completamente distinto) e impegnarlo separatamente.

La vera sfida in tutto questo non è la meccanica è la mentalità - che un commit non è solo una copia di backup che fai ogni tanto, ma che ogni commit è un ciottolo lungo la strada e che non c'è nulla di sbagliato in molti di piccoli commit e che mescolare insieme cose diverse in un commit di mob è altrettanto brutto mettere insieme pezzi di funzionalità vagamente correlati in un grumo di codice.

Per lo meno, allenati ad impegnarti ogni volta che pensi a te stesso "Mi piacciono i miei progressi finora e non voglio perderlo se i cambiamenti che sto per fare sono un disastro". Quindi hai la possibilità di sfruttare il VCS per eliminare tutti i vicoli ciechi che hai provato o il codice di debug speciale che hai aggiunto per rintracciare un problema. (ad es. con git reset --hardo rm -rf *; svn update)

Non c'è una regola dura e veloce, nessuna linea di demarcazione oltre la quale il tuo impegno è troppo grande.

V'è tuttavia una linea guida che impegna più piccoli sono migliori, entro limiti ragionevoli (cioè commettere ogni linea è probaby eccessiva).

Tengo a mente questo tipo di linee guida:

• Un singolo commit dovrebbe includere le modifiche per una sola correzione di bug
• Un singolo commit non dovrebbe includere più di mezza giornata di lavoro
• Un singolo commit non dovrebbe interrompere la build

Certo - questi sono ciò che tengo a mente - YMMV. Sviluppatori diversi favoriscono diversi livelli di granularità.

Più piccolo è il commit, più facile sarà trovare esattamente la provenienza di una potenziale regressione.

Idealmente, un commit dovrebbe essere atomico , nel senso della più piccola modifica coerente alla base di codice (relativa a un bug, funzionalità, ecc.).

Per quanto riguarda i suggerimenti specifici per mantenere ridotte le dimensioni del commit, dipende in gran parte dal VCS e dal modo in cui è configurato: devi essere in grado di eseguire il commit a livello locale o lavorare nella tua filiale sul server.

La chiave è impegnarsi nel tuo ramo "privato" ogni volta che fai un cambiamento atomico, e quindi puoi unire regolarmente il tuo ramo, ad esempio ogni settimana.

Usando un dvcs, il tuo flusso di lavoro potrebbe apparire così:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Utilizzando un vcs centralizzato:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Probabilmente hai sentito il detto che la perfezione è quando non puoi togliere altro. Questo dovrebbe anche descrivere il tuo standard per la dimensione del commit.

Dipende dal tuo progetto dove si trova quella dimensione "perfetta". Se stai spedendo a clienti esterni, una buona dimensione potrebbe essere l'incremento più piccolo che ti sarebbe comodo spedire se non finissi il prossimo in tempo. Se stai costruendo applicazioni interne, spesso distribuite, la dimensione migliore potrebbe essere l'incremento più piccolo che non rompe nulla (e ti avvicina a dove vuoi essere).

I moderni sistemi di controllo della versione ti aiutano a creare buoni commit con ramificazione facile, rebasing interattivo, area di stadiazione, ecc.

I messaggi di commit dovrebbero essere solo una riga (e per git max 60 caratteri). La quantità di codice impegnato deve essere abbastanza piccola da mantenere il messaggio descrittivo entro tale limite.

Tendo a impegnarmi ogni volta (ancora di più ora che siamo passati a git) Ho fatto un pezzo, in quanto consente di catturare il "perché" le cose sono state fatte in questo modo.

A volte hai lavorato tutto il giorno su diversi diversi caschi logicamente distinti e hai dimenticato di impegnare il tuo codice in mezzo. L'uso git citoolpuò essere molto utile per spezzare il tuo lavoro in bei pezzi di dimensioni ridotte alla fine della giornata, anche se non stavi molto attento durante il giorno mentre stavi lavorando.

git citool può consentire di selezionare quali blocchi specifici di un file (o quali righe specifiche) impegnano in un particolare commit, in modo da poter suddividere (non sovrapposte) le modifiche apportate allo stesso file in più commit.

(Sembra che tu usi Subversion. Non conosco uno strumento che lo faccia per Subversion, ma potresti esaminare l'uso git-svndell'adattatore Subversion per git, che ti cambierà la vita.)

Maggiore è il commit, maggiore è la probabilità che tu rompa la build e verrai pagato dal resto della tua squadra. Provo a modificare le modifiche due volte al giorno. Poco prima di pranzo e prima di tornare a casa. Quindi, alle 12:00 e alle 16:30, provo a far funzionare tutto e pronto a impegnarmi. Trovo che questa pratica funzioni per me.

Per rispondere alle tue domande:

1) Per me il commit standard è considerato grande se sta facendo più di una cosa. Per cosa intendo correggere un bug o aggiungere una funzione.

2) Prevenire tali impegni rendendola un'abitudine e una regola da impegnare ogni volta che finisci qualcosa.

3) Nelle fasi semi-precoci dello sviluppo, consento agli commit di includere la prima creazione dei file che verranno utilizzati in seguito.

Vorrei notare che per finito intendo che tutti i bug che puoi identificare sono stati corretti e non romperai la build impegnandoti.

Sì, questo genera un gran numero di commit, ma ti consente di ripristinare esattamente ciò che ha rotto le cose invece di dover eseguire il rollback di una grande serie di modifiche che sono state impegnate nello stesso momento in cui solo una delle modifiche sta causando un problema.

Vorrei anche sottolineare che le regole cambiano un po 'per i sistemi di controllo della versione distribuita (DVCS) come Mercurial e Git. Nel caso tu stia utilizzando uno di questi, esegui il commit ogni volta che hai apportato una modifica, ma non l'hai ancora testato e poi spingi nel repository centrale quando funziona. Questo è preferibile in quanto consente di rivedere più modifiche al codice senza preoccuparsi di interrompere la generazione.

Nel mio caso sto cercando di eseguire il commit dei file di un server nel sistema di repository (SVN). Questo è il commit iniziale e non voglio scaricarlo in quanto è un progetto veramente grande (pochi GB) e voglio fare il commit iniziale dal server client.

Il problema è che il client si trova su un server condiviso, il client svn viene ucciso (o qualsiasi altro software) se viene eseguito più di un minuto.

Un'alternativa sarebbe quella di scaricare il progetto sul mio computer e fare il commit iniziale da lì, ma sono interessato a sapere se esiste un'opzione in SVN per suddividere il commit di grandi dimensioni in qualcosa di più simile ai metodi di transazione.

Lo sviluppatore prima di me non ha mai usato un sistema di controllo della versione.

La società per cui lavoro impone una revisione del codice peer per ogni commit. Pertanto, qualsiasi impegno che rende difficile per un peer capire cosa sta succedendo e rivedere in un ragionevole lasso di tempo, è troppo grande.