Quando eseguire il commit del codice?

Ti impegni quando hai raggiunto uno stato della base di codice che vuoi ricordare. Ci sono molte ragioni per cui potresti voler ricordare uno stato particolare di base del codice, quindi non ci possono essere regole rigide su quando effettuare il commit. Tuttavia, il numero di commit non è sicuramente una misura della qualità o del progresso.

Mi piace pensare alla codifica come arrampicata su roccia in questo contesto. Ti arrampichi un po 'e poi metti un'ancora nella roccia. Se dovessi mai cadere, l'ultima ancora che hai piantato è il punto che ti protegge, così non cadrai mai più di qualche metro. Lo stesso con il controllo del codice sorgente; si codifica un po 'e quando si raggiunge una posizione alquanto stabile, si esegue una revisione. Se dovessi fallire in modo orribile, puoi sempre tornare a quell'ultima revisione e sai che è stabile.

Detto questo, se lavori su una squadra, è consuetudine accertarsi che tutto ciò che si commette sia completo, che abbia senso, che si sviluppi in modo pulito e che non infranga le cose altrui. Se devi apportare modifiche più grandi che potrebbero interferire con il lavoro di altre persone, crea un ramo in modo che tu possa commettere senza disturbare nessun altro.

Dipende anche dal sistema SCM che stai utilizzando. I sistemi distribuiti tipicamente rendono la fusione e la foratura indolori e veloci, e puoi effettuare il commit localmente; questo significa che dovresti impegnarti molto e spingere / unire quando hai fatto una notevole quantità di lavoro. Con sistemi centralizzati come svn o cvs, il commit è più costoso e colpisce tutti. Branching risolve parzialmente questo problema, ma poiché accade sul server, può essere dolorosamente lento e la fusione può essere ingombrante. Pertanto, con gli SCM centralizzati, esiste spesso una cultura più attenta, in cui si impegna solo dopo aver svolto una notevole quantità di lavoro.

Per quanto riguarda l'add-on: Per favore, per favore non farlo. Linee di codice, numero di commit, numero di bug trovati / risolti, ecc. Sono tutte misure molto cattive di qualità o quantità pari.

Se utilizzi DVCS come Mercurial o Git, dovresti impegnarti nel tuo repository locale ogni volta che hai svolto una notevole quantità di lavoro. Tuttavia, è sufficiente inviarlo al repository condiviso solo dopo il suo funzionamento, modifica autonoma che è stata testata.

Per VCS non distribuiti (come ad esempio SVN) si applica la stessa logica, invece del repository locale utilizzare il ramo privato, invece di push-merge al ramo principale.

Dovresti impegnarti presto e spesso.

Conosco persone che si impegnano ogni 90 secondi. Sul serio. Sembra funzionare per loro. Ho sperimentato con il commit ogni volta che salvi un file, che è probabilmente più spesso di 90 secondi. Oggi, probabilmente mi impegno circa ogni 15 minuti. Un VCS che ti consente di schiacciare più commit in uno solo e che consente commit locali (come git) rende tutto molto più semplice.

Quanto spesso dovresti impegnarti? Difficile da dire, ma probabilmente più spesso di quanto lo sei ora. Continua a commettere sempre più spesso, trova un punto che sembra assurdamente troppo spesso, e poi arretra un po '. È probabile che ti ritroverai con qualcosa di ragionevole.

Misuri lo sviluppo di un prodotto in base al valore fornito ai suoi utenti. Non ci sono altre misure accurate.

Si impegna solo quando l'unità ha testato con successo la funzione / modulo / funzionalità specificata e si è ragionevolmente certi che sia pronto per l'integrazione o per il test del sistema.

E per rispondere alle tue domande add-on - NO !! la misura di dove si trova il progetto non dovrebbe mai essere determinata dal numero di commit ... chissà cosa è stato effettivamente commesso? È stato testato con successo o addirittura testato con unità. Solo perché è impegnato, non significa che sia pronto per la produzione.

I commit sono gli elementi costitutivi di qualsiasi codice / codice controllato in versione. Ogni commit dovrebbe fare esattamente uno dei seguenti:

• Aggiungi una nuova porzione di dati o una funzione
• Correggi uno o più bug (un commit per ogni correzione se possibile) dove la correzione può essere:
  • Miglioramento delle prestazioni
  • Correzione del comportamento errato del codice
  • Rimozione errori tipografici
• Rifattorizzare codice o dati senza cambiare la semantica. Ciò comprende:
  • Codice di riscrittura che si comporta identico all'originale
  • Modifica della rappresentazione dei dati in un formato diverso
  • Formattazione di codice o dati per soddisfare le linee guida di formattazione del progetto
• Unisci le modifiche da un altro ramo (a monte / a valle)

Inoltre, quando si lavora nei rami, i commit devono andare in un ramo più adatto. Due commit non dovrebbero avere lo stesso messaggio di commit (che implica cambiamenti simili) ma in rami diversi in quanto confonde i collaboratori. Un modo migliore è il commit sul ramo principale e l'unione al ramo della funzione.

Se i committer seguono la regola precedente, diventa banale a:

• Ripristina una modifica particolare senza effetti collaterali
• Identifica il comportamento che modifica la modifica del codice dalle modifiche alla formattazione del codice
• Unisci tra diversi rami evitando la maggior parte dei conflitti
• Collabora con altri sviluppatori che possono facilmente modificare le tue modifiche

Per quanto riguarda la misurazione dei progressi del progetto in base ai commit, è possibile che il Refactoring commetta e che i commit di Bug fixing non vengano presi in considerazione.

As a add-on: Is it a correct practice to measure a project's development based on its commits?

No. Lì era un WTF quotidiano sul perché è un'idea orribile.

La mia regola generale su come eseguire il codice è effettuare il check-in quando ho completato un blocco di codice e lo compilo. Il chunk non è veramente definito. Se si tratta di un piccolo compito, potrei non effettuare il check-in finché non lo avrò completato. Se è più grande, potrei effettuare il check-in dopo che ciascuna porzione logica è stata completata.

Ma non effettuare il check-in se non viene compilato. So che sembra una cosa stupida da dire ad alta voce, ma ho dovuto spiegarlo alle persone prima.

Crea un commit quando il codice è pronto per essere condiviso con altri utenti del codice - quando è relativamente stabile, sicuro e testato correttamente.

E no, non credo che i commit siano una grande metrica per lo sviluppo di un progetto, perché conosco alcuni sviluppatori che commetteranno ogni piccola e piccola modifica, e altri che commetteranno solo enormi e importanti modifiche alla funzionalità. Come si misura quantitativamente il valore di un commit rispetto ad un altro?

Non appena viene eseguita l'attività corrispondente . Un'attività fa parte di una User story .

Un'attività viene eseguita quando:

• l'unità corrispondente prova passe,
Il codice
• è adeguatamente documentato e
il codice
• è impegnato.

Puoi avere una definizione di fatto .

Non vedo il valore nella misurazione del numero di commit. Tuttavia, se vedi qualcuno che lavora per un lungo periodo sulla stessa user story (o peggio, storie), questo è un odore.

Impegnati in ogni cambiamento significativo che non credi che rompa qualcosa. L'unica cosa che non dovresti commettere sono cambiamenti di stile perché non incorporano cambiamenti nella logica. Altrimenti, più piccole sono le modifiche che commetti, meglio è.

Più piccoli sono i commit, più dettagliato è il modo di documentare il processo di pensiero, che è un aspetto di un buon registro di commit. Una buona revisione del codice non dovrebbe riguardare solo il risultato del codice, ma anche il processo di pensiero.

Inoltre, avere molti piccoli commit rende facile bisecare, una funzionalità troppo usata del controllo della versione, che mi ha permesso di risparmiare molte ore di ricerca di bug dell'ago nelle codebase dei pagliai.

Bisettazione in breve; Scopri un problema nella base di codice corrente. Quindi, seleziona un commit nel log delle modifiche in cui sei sicuro che il problema specifico non esistesse. Inizia con il controllo del commit a metà tra la versione "buona" e quella "cattiva". Verificare se il problema è ancora presente. Se lo è, è necessario guardare più indietro, al centro del "buono" e del commit precedentemente testato. Se il problema è scomparso, è stato introdotto dopo questo specifico cambiamento, quindi è necessario controllare il mezzo tra il "cattivo" e il commit precedentemente testato. Ripetere. Alla fine ti ritroverai con il commit che ha introdotto il problema. Ma solo se hai piccoli commit, altrimenti saprai solo in quale grande ammontare di modifiche il problema si è verificato.

Qui è come funziona con Git ma l'entità si applica a qualsiasi controllo di versione.

Quando:

• costruisce (SEMPRE)
• unit test passa
• funziona (a meno che non sia chiaramente indicato come "work in progress")
• i vantaggi del salvataggio dello stato del codice superano la seccatura di eseguire i test, pensando a un buon messaggio di commit e risolvendo eventuali conflitti di fusione durante il processo di commit