Possible Duplicates:
git / other VCS - how often to commit?
How often should I/do you make commits?
L'utilizzo del controllo del codice sorgente è molto diverso da uno sviluppatore all'altro e da un progetto all'altro. Alcuni si impegnano molto spesso; altri possono trascorrere un'intera giornata o diversi giorni senza impegnarsi (soprattutto quando lavorano al progetto da soli o sanno che altri membri del team stanno lavorando a una parte molto diversa del progetto).
Esempi
A volte, ho visto commesse estremamente piccole, sia nella vita reale che nei webcast e in altri materiali di apprendimento. Alcuni esempi, principalmente dalla vita reale, sono:
-
Un commit che risolve un bug # ... o implementa una feature # ... cambiando una riga di codice.
IMHO, è un caso perfettamente valido per un commit, specialmente se il sistema di tracciamento dei bug è collegato al controllo della versione e viene aggiornato automaticamente in base alle revisioni. Anche senza questo link, è utile tenere traccia di quale commit ha risolto cosa, indipendentemente dal numero di modifiche richieste per risolvere un bug o implementare una funzionalità.
-
Un commit che modifica una singola impostazione di configurazione (dato che nel contesto, le impostazioni di configurazione devono essere nel controllo sorgente).
IMHO, questo potrebbe essere unito a volte con un altro commit, a meno che l'impostazione precedente non rompa la build o introduca un bug o possa influenzare altri sviluppatori (ad esempio una stringa di connessione modificata dopo la migrazione del server del database di test).
-
Un commit che corregge l'ortografia di una parola, ad esempio in una stringa visualizzata all'utente.
IMHO, nella maggior parte dei casi, questo può essere unito a un altro commit (a meno che, di nuovo, non si rompa la build). L'unico caso in cui non può essere unito è quando, se lasciato, l'ortografia sbagliata può essere propagata attraverso il codice e sarebbe troppo complicata o impossibile da modificare in seguito, come con HTTP referer header .
-
Un commit che aggiunge un commento a un metodo (mentre il metodo era già abbastanza esplicito) o risolve un'altra regola secondaria relativa allo stile.
Esempio: in .NET Framework, StyleCop richiede di documentare ogni metodo, e il commento XMLDoc per un costruttore (che è anche il metodo) deve iniziare con:
Initializes a new instance of the <Class name here> class.
Un commit può applicare questa ultima regola, sostituendo un commento nel codice precedente:
Creates a new vehicle with the specified number of wheels.
da:
Initializes a new instance of the Vehicle class, using the specified number of wheels.
In altre parole, la revisione non ha altro significato se non quello di conformare la parte di codice agli standard di stile usati nella base di codice.
IMHO, questo può essere unito ad un altro commit in ogni caso (dopotutto, le regole relative allo stile devono essere applicate in commit per rifiutare i commit del codice che non corrisponde a loro), a meno che ci siano diverse modifiche in diversi posti.
Domande
Mi sbaglio su quei punti?
Esiste un impegno troppo piccolo o è pratica di commettere molto spesso una pratica migliore?
Vale la pena di commettere modifiche troppo piccole, dato che "inquinerebbe" il registro di revisione e renderebbe più difficile trovare le modifiche rilevanti tra piccoli cambiamenti a cui nessuno si preoccupa e che non rompono o non infrangono la costruzione, né influire su altri sviluppatori?