Sul miglioramento delle pratiche di commit

Se stai usando un DVCS, dovresti commettere molto spesso. Mi impegno ogni volta che il mio codice è in uno stato stabile, che non è correlato a linee di codice. Vuoi un albero di molti piccoli, commessi atomici che ti rendano facile vedere cosa hai fatto in ciascuno di essi. Se stai cercando di rintracciare una regressione che hai trovato durante il test, questo rende molto più facile fare una ricerca binaria e rintracciare il commit esatto, perché avrai meno modifiche per commit. Mi impegno solo quando compilo il mio codice: la mia idea di "atomico" è che compila, supera i test delle unità di regressione e passa un rapido test di integrazione. A volte è incluso un test unitario, a volte no.

Quando premi, devi spingere intere funzionalità. Il resto del mondo non vuole vedere che il tuo "mancato controllo in questo file" si impegna ogni giorno. Git fornisce rebase , che ti consente di pulire la tua struttura di commit schiacciando più commit insieme. La comunità sembra essere incerta su quanta storia dovresti impegnarti. Direi che dovresti mettere insieme i commit che non mostrano alcuna storia, come "file mancato" o "regressione stupida". Vuoi presentare una cronologia più pulita che puoi in modo che tutti possano vedere facilmente cosa hai fatto.

In un sistema di controllo della versione centralizzato, devi impegnare molto di più se vuoi mantenere una buona storia. La mia raccomandazione è di lavorare su funzionalità più piccole e completarle il più possibile prima di eseguire il commit. Il tuo concetto di "atomico" dovrebbe essere una funzionalità che funziona e viene testata. Non vuoi impegnare nulla che rompa gli spazi di lavoro di altri sviluppatori, perché si aggiorneranno spesso ed è molto più difficile lavorare su funzionalità indipendenti che si sovrappongono. Impegnerai meno, ma quei commit saranno solitamente più carnosi del tuo DVCS medio.

Puoi vedere che il rapporto tra le righe di codice e il numero di commit dipende da quanto sono grandi le tue funzionalità e dal flusso di lavoro che usi. Il tuo flusso di lavoro sarà diverso a seconda del sistema di controllo della versione che utilizzi, quindi in genere non puoi prevedere quale sarà il tuo commit. Ogni istituzione ha il proprio standard e dovrebbe determinare da sé quale dovrebbe essere idealmente il proprio flusso di lavoro.

Ho avuto commit per correzioni di bug che hanno cambiato un carattere . La dimensione non è davvero il fattore determinante qui. Una buona regola è quella di impegnarsi ogni volta che si può pensare a un messaggio di commit che abbia senso. Quando condividere i tuoi commit è una domanda diversa. Varia in base alla cultura del tuo gruppo, ma in genere ti consente di essere ragionevolmente sicuro che le tue modifiche funzionino come previsto.

Non penso che il numero di commit debba essere correlato al numero di linee. Più probabile problemi risolti / funzionalità introdotte. Io uso questo approccio piuttosto semplice (git):

• Impegnarsi spesso in una filiale locale, ma solo quando qualcosa di rilevante cambia (risolto problema sconcertante, aggiunto alcuni file / funzioni importanti). In questo modo, puoi navigare facilmente tra i passaggi che ti hanno portato alla soluzione finale di ciò che stavi lavorando in un dato momento.
• Unisci i commit locali in una singola funzione / commit relativo ai problemi quando si invia a un repository remoto / pubblico. In questo modo, qualunque cosa tu abbia fatto pubblicamente, è ben descritta e coerente, in modo che tutti sappiano cosa stavi facendo (o almeno ha una breve idea).

Nel complesso, qualunque cosa tu faccia localmente è per te - tieniti ad avvicinarti a quello che funziona per te. I commit pubblici dovrebbero essere più pensati, ma non svilupperei una strategia completamente nuova se il team ha già un approccio di lavoro. Rimani coerente con gli altri.

Per i posteri, commetti tutti i file relativi a un bug / funzionalità in una revisione. Questo ti aiuterà immensamente più tardi quando avrai bisogno di sapere quali file sono stati toccati per correggere un bug.

Rende più facile tornare indietro e vedere cosa hai fatto per vedere 5 file archiviati sotto bug # 783, invece di cercare di rintracciare 5 commit (uno per ogni file). Questo può essere alleviato se si dispone di un migliore controllo del sorgente / integrazione del flusso di lavoro che corrisponde a un check-in per un lavoro / bug / funzionalità / backlog. Continua a commettere frequentemente, ma metti file / funzionalità correlate nello stesso check-in ogni volta.

Se hai impostato il CI per "build every commit", allora questo ti aiuterà a farlo.