Quanto dovrebbe essere grande un singolo commit? [duplicare]

Sono andato alla ricerca di riferimenti ai libri per questo, ma purtroppo non li trovo.

In generale, credo che i piccoli commit siano ampiamente considerati le migliori pratiche. O più precisamente: il commit più piccolo che rappresenta una feature coesiva che è in uno stato compatibile.

Perché?

1. Piccoli e frequenti check-in ti impediscono di perdere il lavoro in caso di guasto dell'hardware, terremoto, apocalisse di zombi.
2. I tuoi colleghi possono ottenere i tuoi cambiamenti prima che se aspetti fino alla fine e facciano un grosso commit.
3. Se è necessario eseguire il rollback di una funzione, puoi eseguire il rollback di un changeset diverso da "metà" di un changeset.
4. I check-in più piccoli significano meno aree di cambiamento, il che significa meno probabile conflitto con il lavoro di altre persone.

Sono quasi sicuro che ci sia una buona dose di opinione in questo spazio, ma tendo a seguire alcune regole da cui tende a dettare le dimensioni dei commit, alcune riflessioni su questo:

1. I singoli commit dovrebbero essere "rollback-able", la tua funzione ha un impatto sulla capacità di lavoro del sistema se il commit è stato lanciato? I commit dovrebbero essere unità coesive e quelle unità coesive dovrebbero "mappare" correttamente (il più possibile) nella funzionalità.
2. Fila in privato dove possibile per proteggere la "brutta" dalla tua squadra, in definitiva i tuoi commit, grandi o piccoli, non dovrebbero influire sul loro lavoro sulla caratteristica B.

Penso che se segui entrambe le regole generali, i tuoi commit potrebbero o meno necessariamente essere "grandi" o "piccoli" (relativamente parlando). Certo, i piccoli commit sono buoni, ea volte più facili da ragionare, ma se sono tutti strongmente accoppiati, potrebbe renderlo un po 'più difficile da gestire. Sto bene con un commit "grande" (entro limiti ragionevoli) a patto che sia ridotto al suo raggruppamento funzionale coesivo più piccolo.

Preferisco il tuo approccio quando usi Mercurial. I moderni sistemi di controllo del codice sorgente come Git e Mercurial si basano sull'idea che i commit rapidi ti permettono di impegnarti frequentemente. Non dovresti salvare un gran numero di modifiche e impegnarle in un colpo solo.

Git ti permette di condensare più commit in un singolo commit usando la sua funzione "squash", ma questo non è fornito di default in Mercurial. La modifica della cronologia dei commit va contro l'ethos Mercurial, che afferma che la storia dovrebbe essere immutabile. Tuttavia, se vuoi provare a replicare la funzione di schiacciamento di Git - in modo che tu possa continuare a utilizzare i tuoi strumenti correttamente, pur continuando ad aderire al nocciolo del tuo lead dev - questa domanda potrebbe aiutarti:

link

Esistono argomenti validi in entrambi i casi, da un lato, il controllo del codice sorgente non è un meccanismo di backup, si dovrebbe usare shelving, un repository locale o un semplice backup vecchio per assicurarsi che il proprio lavoro sia sicuro fino al commit alla produzione. D'altra parte, se una serie di modifiche rappresenta una correzione completa e discreta di bug, funzionalità, ecc., Allora sembra ragionevole impegnarle quando sono pronte. In futuro, rivedere i commit più piccoli e più "modulari" potrebbe rivelarsi più semplice piuttosto che sfiorare una revisione con 100s di file modificati.

Inoltre, cercare di mantenere la purezza in un log di controllo sorgente sembra un gioco perdente a lungo termine e si concentra sulla gestione di un artefatto del processo di sviluppo piuttosto che sul software stesso.

Porta la tua cronologia dei commit, come esempio per il tuo progetto personale. Ci sono 13 messaggi di commit per 1 giorno (ad esempio "2 giorni fa"). Ora immagina come sarebbe la storia per lo stesso periodo di tempo se gli sviluppatori 50-200 + hanno lavorato al progetto nello stesso modo. Questo è 650-2600 messaggi di commit al giorno . La cronologia dei commit per una settimana sarebbe intrattabile per un umano.

Quindi dipende dalle dimensioni del team: su piccole squadre, sono buone informazioni dettagliate. Man mano che la squadra diventa più grande esplode rapidamente in un casino di rumore, rendendo la storia funzionalmente inutile.

• Non commetti mai deliberatamente un commit che lascerà il repository in uno stato di errore, anche se intendi creare un altro che lo risolva.

• Preferisci piccoli commit a grandi commit. Quando si rintraccia la fonte di alcuni problemi tagliando il repository, è più facile rintracciare la fonte di un problema se i passaggi sono piccoli; ed è più facile comprendere rapidamente le modifiche in un piccolo commit.

• Preferisci un singolo commit per una singola funzione, correzione o altra unità logica di lavoro; evitare commit "parziali" che introducono modifiche che non sono funzionali senza ulteriori commit ed evitare commit composti che contengono diverse modifiche non correlate. Se stai apportando una modifica stilistica che non modifica la funzionalità, eseguila separatamente. Tutto ciò aumenta la probabilità di lasciare la build ininterrotta, e rende molto più facile per un'altra persona scaricare i problemi della base di codice per capire la sequenza di cambiamenti funzionali avvenuti e cogliere rapidamente ogni singola modifica.

• Se stai lavorando su una funzione molto complessa o un refactoring che non può essere reso sicuro o utile da impegnare mentre parzialmente scritto, lavorare su un ramo privato, impegnarsi spesso, cerca di rimanere aggiornato con il trunk, e se possibile, quando finalmente si fondono in trunk, fallo in un modo che lasci ai futuri manutentori un modo per accedere alla cronologia del ramo privato.

Quindi, per riassumere: cerca sempre di fare il più piccolo impegno possibile che sia sia necessario che sufficiente per completare una singola unità logica di lavoro.