git / altri VCS - quanto spesso impegnarsi? [duplicare]

Ogni singola modifica dovrebbe essere un commit. Alcune cose da considerare:

• Avere roba impegnata significa che puoi eseguire il rollback. Supponi di avere un compito più grande da fare. Hai finito il 50%, quella parte sembra buona finora. Quindi continui e rompi qualcosa in modo massiccio con un errore. Avere il commit in mezzo significa che puoi tornare indietro e non perdere tutto il lavoro.
• Il controllo della versione non è un posto dove scaricare dati e dimenticare. Il controllo della versione fornisce una cronologia. Lateron puoi usare la cronologia, inclusa la mia funzione di annotazione preferita, per capire perché è stato fatto un cambiamento (e chi è responsabile) questo spesso aiuta. Ma per funzionare correttamente, il cambiamento dovrebbe essere limitato e autonomo.
• Lavorando in team è bello avere persone che lo recensiscono (in realtà anche lavorando da solo sarebbe fantastico ;-)), per una recensione è bene avere piccole parti che possono essere riviste senza essere mescolate tra le modifiche non correlate.

Esaminando git in modo specifico: git consente i commit locali, che non danneggiano gli altri, quindi può anche essere accettabile eseguire il commit di codice rotto localmente e correggerlo con un commit successivo prima di premere. Gli sviluppatori di git sono orgogliosi della velocità con cui opera l'operazione di commit, quindi l'intervento locale non interrompe realmente il processo di sviluppo. Git consente anche la riscrittura dei commit, quindi questi due (o più) commit potrebbero essere riscritti in uno prima di essere spinti, il che potrebbe facilitare la revisione - mentre le riscritture sono pericolose e dovrebbero essere eseguite con cura (non riscrivere dopo push ecc.)

Quando si tratta di git, credo che si dovrebbe impegnarsi il più spesso possibile - alcune persone impegnano ogni compilation di successo. Non confondere i commit con i push: non è necessario spingere un commit locale (e con git, dovresti usare molti rami perché sono economici).

Questo dovrebbe essere la regola tutt'intorno, ma alcuni SCM sono troppo lenti per tale regola.

Personalmente, quando utilizzo SVN, provo a eseguire il commit più volte al giorno e solo quando sono certo che il codice sia in buone condizioni (ovvero compila e passa tutti i test).

Ti impegni quando puoi scrivere un messaggio di commit (scrivi quelli giusti ... :) che descrive chiaramente la singola nuova funzione / funzione / bugfix / miglioramento incluso nel commit.

Se stai correggendo bug indipendenti, dovrebbero essere commit separati. Il motivo è che, se in seguito trovi un problema con la correzione del bug A, e vuoi invertire, è molto più semplice se non è combinato con bug B e C. Soprattutto se è stato eseguito il commit di codice aggiuntivo prima di aver trovato il problema. La stessa logica si applica anche alle funzionalità. Fondamentalmente, la più piccola unità di codice di lavoro che qualcun altro può controllare e utilizzare. Anche se quella persona sei tu su un'altra macchina.

I piccoli commit non sono esattamente così male quando si tratta chiaramente di correggere cose specifiche. È comprensibile che la cronologia delle revisioni possa essere affollata, ma può anche fornire spunti interessanti sullo stile di sviluppo del team di progetto. Quando un nuovo sviluppatore si unisce al progetto, può essere utile per lui / lei leggere l'elenco della cronologia delle revisioni se le modifiche sono descritte in modo sufficientemente chiaro.

Tuttavia, ci sono alcune linee guida che variano da progetto a progetto. Alcuni hanno serie di test che devono essere eseguiti correttamente prima di poter eseguire il commit del codice, altri sono configurati per eseguire automaticamente i test dopo (un utile esempio di servizio di test di integrazione continua pubblico è Travis CI).

La risposta varierà anche in base al tipo di sistema di gestione delle versioni utilizzato nel progetto. Avendo utilizzato prevalentemente strumenti di tipo DVCS, ritengo che possa essere utile ricordare a me stesso di effettuare piccoli commit in quanto funziona anche come documentazione parziale. Una quantità eccessiva di commit minori può essere fonte di confusione all'inizio, ma secondo ricerca , la maggior parte dei commit nei progetti Open Source sono piccoli. Potrebbero esserci differenze nel modo in cui funziona lo sviluppo interno, ma spesso sono le piccole cose che iniziano a infastidire gli strumenti e piccole modifiche spesso sono sufficienti per risolvere problemi specifici.

Alcuni dei possibili motivi per tenerlo piccolo:

"You should try to split your changes into small logical steps, and commit each of them. They should be consistent, working independently of any later commits, pass the test suite, etc."

Hai trovato un alias utile per visualizzare l'elenco dei commit git in console. lg ha davvero aiutato a vedere le modifiche più velocemente e in modo più chiaro rispetto a varie altre visualizzazioni dell'elenco di commit:

# Show history in short format with colors
alias lg="git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative"

Mi sforzo sempre di avere il mio registro di commit simile al log delle modifiche per il mio programma. Questo non è un obiettivo raggiungibile, ma qualcosa per cui lottare. Praticamente definisce che voglio un commit separato per ogni nuova funzionalità e ogni bugfix, ma non troppe.

Inoltre, quando lavoro in una squadra, penso a un impegno come una lettera a un altro sviluppatore, che descrive il cambiamento che ho fatto. Non voglio inviare spam ai miei compagni con ogni piccolo impegno che faccio nello sviluppo di una nuova funzionalità. Lasciare un'impressione molto migliore se produco solo un commit più grande, come se avessi scritto la funzione in modo impeccabile al mio primo tentativo.

Ma d'altra parte non voglio cadere nell'oscurità solitaria ... passare un mese a creare un enorme impegno perfetto. Voglio mantenere i miei colleghi sviluppatori consapevoli dei miei progressi. Qualsiasi grande caratteristica può solitamente essere suddivisa in parti significative. Quindi, come regola generale, un impegno pubblico al giorno dovrebbe essere il minimo.