La cronologia delle versioni è davvero sacra o è meglio ribasare?

La cronologia è sacra, il presente non lo è. Puoi dividere il tuo "albero" DVCS in due parti:

• La passata / history che contiene una visualizzazione accurata di come hai raggiunto lo stato corrente del codice. Questa parte della cronologia cresce nel tempo

• Il presente a quale parte stai lavorando per far evolvere il tuo codice. Questo suggerimento per la maggior parte della cronologia ha sempre le stesse dimensioni.

Ogni codice che hai pubblicato o usato in qualche modo fa parte del passato . Il passato è sacro perché è necessario essere in grado di riprodurre una configurazione o capire cosa ha introdotto una regressione. Non dovrai mai riscrivere il passato . In git di solito non riscrivi mai nulla una volta che è in master: master è la parte passata della cronologia. In Mercurial hai questo concetto di fase pubblica che tiene traccia della parte passata del tuo "albero" "e applica la sua immutabilità.

La parte presente del codice è il changeset su cui stai lavorando. Il ramo di funzionalità che stai cercando di rendere utilizzabile, privo di bug e correttamente refactored. È perfettamente corretto riscriverlo è anche una buona idea perché rende la parte precedente più carina, semplice e utilizzabile. Mercurial traccia questo nella fase bozza .

Quindi sì, ti preghiamo di rebase se migliora la tua cronologia. Mercurial ti impedirà di spararti ai piedi se stai rifondando cose che non dovresti.

Non tutti gli errori sono del tipo che è necessario nascondere, ad esempio, una volta ho accidentalmente eseguito un file binario nel mio repository. La manomissione della cronologia è solo negativa quando l'errore non è esclusivamente nella cronologia stessa, come i file impegnati che non dovrebbero essere.

La revisione del codice è molto più semplice quando c'è un grosso cambiamento coesivo rispetto a molti piccoli dipendenti.

Quando lavoro su una nuova funzione, mi piace commettere un sacco di piccoli cambiamenti nella mia filiale. Quando sono pronto per inviare la patch, collasso quei piccoli commit in un grosso commit che rappresenta tutto il nuovo codice richiesto per quella funzionalità. Qui è dove rebase è utile.

D'altro canto, rebase è sconsigliato se i commit non hanno nulla a che fare l'uno con l'altro. Più aggiunte di caratteristiche dovrebbero essere commit separati (e idealmente provengono da rami separati).

La tua domanda descrive la cronologia come una serie di modifiche al codice ordinate, e chiede se indizi organici indichino o meno futuri lettori nel processo di sviluppo. Eppure come una versione / ingegnere dell'integrazione, non penso spesso alla storia come al codice. Sono di più assorbito dalla storia che racconta la mia storia, la conoscenza istituzionale mantiene e se mi consente o meno di eseguire rapidamente il debug dei problemi.

Non penso che i flussi di lavoro organici lo facciano bene, anche il mio. Qualità che valore su DVCS quando sto codificando - filiali economiche, commit rapidi, salva in remoto presto e spesso - non sono quello che apprezzo come la integrazione della mia azienda manager. Emetto git rebase , git merge , git diff e git apply molto più spesso in quel ruolo di git add o git commit . Strumenti come rebase mi permettono di trasforma il codice che mi è stato dato da qualcosa in cui funzioni qualcosa che può essere mantenuto.

I commit illogici o vaghi non sono utili, ma sono peccaminosamente facili da scrivere organicamente, quando la preoccupazione principale è far funzionare il codice, non distribuirlo ad altri. Commits come Case 15: Fixed a problem , o Refactored <cranky legacy feature> rendono la mia auto-compiacenza, anche quando li autore. Nessuno, tuttavia, induce la rabbia blackout come commit "incrementale". Considera questo argomento che uno sviluppatore mi ha consegnato l'altro giorno:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

Queste cose sono malvagie. È come se il DVCS fosse progettato per il Dr. Faustus. darò controllo sorgente facile e veloce. Tu mi dai il tuo codice anima del manutentore. Tutti i commessi pigri sono atti egoistici. Molti di noi li scrivono, ma dobbiamo anche i nostri sé futuri logici, replicabili, storia debuggable. Non possiamo farlo senza alcuno sforzo a rebase .

Per quanto riguarda gli esperimenti falliti, perché non descriverli nei nostri messaggi di commit (recentemente pristine)? A un anno da ora non ho bisogno di un frammento mezzo finito. Voglio solo una registrazione del tentativo abortito, e forse una breve spiegazione se penso di essere abbastanza sciocco da provare di nuovo. Ci sono molti flussi di lavoro di successo nel mondo, ma non riesco a pensare a nessuna ragione per cui ordinerò deliberatamente codice spezzato a una base di codice di produzione.

Niente dovrebbe essere sacro, ma assicurati di avere delle buone ragioni per quello che stai facendo. Rebasing è estremamente potente se usato correttamente, ma come con qualsiasi strumento potente può creare confusione e causare problemi se usato con noncuranza.

Personalmente trovo molto utile rebase di un ramo di funzionalità locale contro trunk (o ramo di sviluppo principale) prima di eseguire i test finali e unire la funzione nel ramo principale. In questo modo riesco a gestire eventuali conflitti di fusione ecc. Prima di fonderci.

IMHO, gli esperimenti di solito appartengono agli scaffali o ai rami temporanei, non alle linee di base. Se segui questo, non dovrebbe esserci un problema, poiché tutti i commit saranno logicamente validi e aggiungeranno qualche valore.