I commit possono essere considerati troppo piccoli? [duplicare]

14

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?

    
posta Arseni Mourzenko 23.02.2012 - 18:49
fonte

4 risposte

31

La parola sbagliata è troppo strong, perché è una questione di stile / preferenza. Tuttavia, la mia preferenza è apparentemente diametralmente opposta alla tua.

Preferisco di gran lunga vedere le modifiche allo stile di codifica e le piccole modifiche alla documentazione eseguite nei propri commit. Se sto facendo una revisione del codice o cercando di capire dove è stato introdotto un bug, è molto più facile se ogni commit non tocca una mezza dozzina di problemi casuali. Nel mio mondo un commit ideale corregge un bug o completa una funzionalità. In questo modo, se la correzione o la nuova funzione risulta avere qualche problema serio, il backup è molto più semplice: non devi cercare di districare un grab-bag di modifiche non correlate al problema.

Ora, se hai una serie di modifiche che riguardano solo la documentazione / la formattazione, sentiti libero di raggrupparle insieme e il tuo commento di commit dovrebbe indicare "Solo modifiche alla formattazione / documentazione".

    
risposta data 23.02.2012 - 19:08
fonte
8

Prima di tutto, non penso che ci sia una risposta a questa domanda. Come fai notare, differisce molto tra individui e progetti.

Applico qualcosa come l'idea di SoC (Separation of Concerns) in commit. Cioè, cerco di impegnarmi su una base "per compito". In altre parole, evita di impegnare "diverse aree di lavoro" contemporaneamente. In questo senso, non esiste un impegno troppo piccolo.

    
risposta data 23.02.2012 - 19:06
fonte
5

I piccoli commit sono grandiosi. IMHO, più piccolo è, meglio è. In particolare, i piccoli commit sono buoni perché sono facilmente controllabili. Preferirei rivedere 5 piccoli cambiamenti indipendenti rispetto a 1 cambiamento più grande che li incorpora tutti.

    
risposta data 23.02.2012 - 19:28
fonte
3

Non penso che nessun commit possa essere troppo piccolo purché il commento sia accurato; la mancanza o l'ingannevolezza dei commenti di commit sono riprovevoli.

Personalmente preferisco commettere modifiche nei gruppi logici, ad es. un commit per il refactoring prima di apportare modifiche logiche, poi un altro per le modifiche per correggere il bug.

Preferisco anche che i commenti contengano alcuni dettagli, quindi esaminerò tutti i file che sono cambiati per raccogliere le modifiche correlate che possono essere trattate dallo stesso commento, separando quelle che necessitano di dettagli che non si applicano a altri file.

    
risposta data 23.02.2012 - 19:23
fonte

Leggi altre domande sui tag