Quando eseguire il commit del codice?

Quando si lavora su un progetto, il codice può essere sviluppato abbastanza velocemente in un solo giorno o bit per bit per un periodo prolungato di poche settimane / mesi / anni. Poiché i commit del codice stanno diventando considerati come una misura dello sviluppo del progetto, ciò non significa che abbia più codice scritto di un progetto che ha meno commit.

Quindi la domanda è quando effettuare davvero un commit nel repository in modo che il commit sia giustificabile?

Come componente aggiuntivo: è una pratica corretta misurare lo sviluppo di un progetto in base ai suoi impegni?

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

Mi piace pensare alla programmazione 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, quindi non cadrai mai più di qualche metro. Lo stesso con il controllo del codice sorgente; codice un po ', e quando raggiungi una posizione un po' stabile, commetti una revisione. Se dovessi mai fallire in modo orribile, puoi sempre tornare all'ultima revisione e sai che è stabile.

Detto questo, se lavori in una squadra, è consuetudine assicurarsi che tutto ciò che commetti sia completo, abbia senso, costruisca in modo pulito e non rompa le cose di qualcun altro. Se devi apportare cambiamenti più grandi che potrebbero interferire con il lavoro di altre persone, crea una succursale in modo da poterti impegnare senza disturbare nessun altro.

Dipende anche dal sistema SCM che stai utilizzando. I sistemi distribuiti in genere rendono la fusione e il biforcazione indolori e veloci e puoi impegnarti localmente; questo significa che dovresti impegnarti molto e spingere / unire quando hai svolto una notevole quantità di lavoro. Con sistemi centralizzati come svn o cvs, il commit è più costoso e riguarda tutti. La ramificazione risolve parzialmente questo problema, ma poiché si verifica sul server, può essere dolorosamente lento e l'unione può essere complicata. Quindi, con gli SCM centralizzati, c'è spesso una cultura più attenta, in cui ti impegni solo dopo aver svolto una notevole quantità di lavoro.

Per quanto riguarda il componente aggiuntivo: per favore, per favore non farlo. Le righe di codice, il numero di commit, il numero di bug trovati / risolti, ecc., Sono tutte misurazioni pessime di qualità o quantità pari.

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

Per i VCS non distribuiti (come ad es. SVN) si applica la stessa logica, invece del repository locale utilizzare la diramazione privata, anziché push - unisci alla diramazione principale.

Dovresti impegnarti presto e spesso.

Conosco persone che commettono ogni 90 secondi. Sul serio. Sembra funzionare per loro. Ho provato a impegnarmi ogni volta che salvo un file, che probabilmente è più spesso di 90 secondi. Oggi, mi impegno probabilmente ogni 15 minuti circa. Un VCS che ti consente di comprimere più commit in uno e che consente commit locali (come git) lo rende molto più semplice.

Quanto spesso dovresti impegnarti? Difficile a dirsi, ma probabilmente più spesso di quanto lo sia ora. Continua a impegnarti sempre più spesso, trova un punto che sembra assurdamente troppo spesso e poi indietreggia un po '. È probabile che finirai con qualcosa di ragionevole.

Misuri lo sviluppo di un prodotto in base al valore fornito ai suoi utenti. Non esistono altre misurazioni accurate.

I commit sono i mattoni di qualsiasi dato / codice controllato dalla versione. Ogni commit dovrebbe eseguire esattamente una delle seguenti operazioni:

• Aggiungi un nuovo dato o 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 di errori tipografici
• Codice di refactoring o dati senza cambiare la semantica. Ciò comprende:
  • Riscrivere il codice che si comporta in modo 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 in filiali, gli commit devono andare in una filiale più adatta. Due commit non dovrebbero avere lo stesso messaggio di commit (implicando cambiamenti simili) ma in rami diversi poiché confonde i collaboratori. Un modo migliore è eseguire il commit nel ramo principale e unire il ramo della funzione.

Se i committer seguono la regola sopra, diventa banale:

• Annulla una modifica particolare senza effetti collaterali
• Identificare 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 apportare facilmente le tue modifiche

Per quanto riguarda la misurazione dello stato di avanzamento del progetto in base ai commit, è possibile se i commit di refactoring e i commit di bug fixing non vengono presi in considerazione.

Effettuare il commit solo quando l'unità ha testato con successo la data funzione / modulo / funzionalità e si è ragionevolmente certi che sia pronta per l'integrazione o il test del sistema.

E per rispondere alle tue domande aggiuntive - 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 sul sistema o addirittura testato sull'unità. Solo perché è impegnato - non significa che sia pronto per la produzione.

Come componente aggiuntivo: è una pratica corretta misurare lo sviluppo di un progetto in base ai suoi impegni?

No. C'era un WTF quotidiano sul perché questa è un'idea orribile.

La mia regola generale sul commit del codice è quella di effettuare il check-in quando ho completato un pezzo di codice e questo viene compilato. Chunk non è veramente definito. Se è un compito piccolo, potrei non fare il check-in fino a quando non lo avrò fatto. Se è più grande, potrei fare il check-in dopo che ogni porzione logica è stata completata.

Ma non effettuare mai il check-in se non viene compilato. So che sembra una cosa stupida da dire a voce alta, ma prima l'ho dovuto spiegare alla gente.

Effettua 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 cambiamenti alla funzionalità. Come si misura quantitativamente il valore di un commit rispetto a un altro?

Non appena l' attività corrispondente viene eseguita . Un compito è una parte di una storia dell'utente .

Un'attività viene eseguita quando:

• i corrispondenti test unitari passano,
• il codice è adeguatamente documentato e
• il codice è stato commesso.

Puoi avere una diversa definizione di fatto .

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

Commetti ogni cambiamento significativo che non pensi rompa qualcosa. L'unica cosa che non dovresti commettere sono i cambiamenti di stile perché non incorporano cambiamenti nella logica. Altrimenti, minori sono le modifiche che commetti, meglio è.

Più piccolo è il commit, più dettagliato è possibile 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 lo rende facile da dividere in due, una funzionalità troppo poco utilizzata per il controllo della versione, che mi ha risparmiato molte ore nella ricerca di bug dell'ago nelle basi di codici del pagliaio.

Bisecare 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 checkout nel mezzo tra la versione "buona" e la "cattiva". Prova per vedere se il problema è ancora presente. Se lo è, è necessario guardare più indietro, nel mezzo del "buono" e del commit precedentemente testato. Se il problema è risolto, è stato introdotto dopo questa specifica modifica, quindi è necessario controllare il punto intermedio tra il "cattivo" e il commit precedentemente testato. Ripetere. Alla fine finirai con il commit che ha introdotto il problema. Ma solo se hai piccoli impegni, altrimenti saprai solo in quale grande mucchio di cambiamenti è emerso il problema.

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

Quando:

• costruisce (SEMPRE)
• test unitari superati
• funziona (a meno che non sia chiaramente indicato come "lavori in corso")
• i vantaggi di salvare lo stato del codice superano la seccatura di eseguire i test, pensare a un buon messaggio di commit e risolvere eventuali conflitti di unione durante il processo di commit