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

Sono sempre stato d'accordo con il mantra ^{1 di} Mercurial , tuttavia, ora che Mercurial viene fornito in bundle con l'estensione rebase ed è una pratica popolare in git, mi chiedo se possa davvero essere considerata una "cattiva pratica", o almeno abbastanza male da evitare l'uso. In ogni caso, sono consapevole che il rebasing è pericoloso dopo aver spinto.

OTOH, vedo il punto di provare a impacchettare 5 commit in uno solo per renderlo più nitido (specialmente in un ramo di produzione), tuttavia, personalmente penso che sarebbe meglio essere in grado di vedere commit parziali per una caratteristica in cui alcuni la sperimentazione è fatta, anche se non è così elegante, ma vedere qualcosa come "Ho provato a farlo in modo X ma non è ottimale come Y dopo tutto, facendolo Z prendendo Y come base" IMHO avrebbe un buon valore per chi studia la base di codice e seguire il percorso di pensiero degli sviluppatori.

Il mio punto di vista molto ponderato (come in quello stupido, viscerale, di parte) è che ai programmatori piace rifarsi per nascondere gli errori ... e non penso che ciò vada bene per il progetto.

Quindi la mia domanda è: hai davvero trovato prezioso avere tali "commit organici" (cioè una storia non manomessa) in pratica? O, al contrario, preferisci incorrere in impegnativi ben confezionati e ignorare il processo di sperimentazione dei programmatori ?; qualunque tu abbia scelto, perché funziona per te? (avere altri membri del team per conservare la storia o, in alternativa, riprogrammarla).

¹ per analisi DVCS di Google , in Mercurial "History is Sacred".

La storia è sacra, il presente no. Puoi dividere il tuo "albero" DVCS in due parti:

• Il passato / storia che contiene una visione accurata di come hai raggiunto lo stato corrente del codice. Questa parte della storia cresce nel tempo

• Il presente su cui stai attualmente lavorando per far evolvere il tuo codice. Questo suggerimento gran parte della storia ha sempre le stesse dimensioni.

Ogni codice che hai rilasciato o utilizzato in qualche modo fa parte del passato . Il passato è sacro perché devi essere in grado di riprodurre una configurazione o capire cosa ha introdotto una regressione. Non riscriverete mai più il passato . In genere di solito non riscrivi mai nulla una volta che è in master: master è la parte passata della storia. In Mercurial hai questo concetto di fase pubblica che tiene traccia della parte passata del tuo "albero" e impone la sua immutabilità.

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

Quindi sì, ti preghiamo di riformulare se migliora la tua cronologia. Mercurial ti impedirà di spararti al piede se stai ribattendo cose che non dovresti.

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

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

Quando lavoro su una nuova funzionalità, mi piace impegnare molte piccole modifiche nel mio ramo. Quando sono pronto a inviare la patch, comprimo quei piccoli commit in un unico commit che rappresenta tutto il nuovo codice richiesto per quella funzione. Questo è dove rebase è utile.

D'altra parte, rebase è sconsigliato se i commit non hanno nulla a che fare l'uno con l'altro. Le aggiunte multiple di funzionalità dovrebbero essere commit separati (e idealmente provengono da rami separati).

La tua domanda descrive la storia come un insieme di modifiche al codice ordinate e chiede se organico impegna o meno i futuri lettori nel processo di sviluppo. Tuttavia, come ingegnere del rilascio / integrazione, non penso spesso alla storia come a un codice. Sono più assorbito dalla storia che la mia storia racconta, dalle conoscenze istituzionali che conserva e dal fatto che mi permetta o meno di eseguire il debug dei problemi.

Non penso che i flussi di lavoro organici lo facciano bene, anche i miei. Le qualità che apprezzo di DVCS quando sto programmando - filiali economiche, impegni rapidi, risparmi sul telecomando in anticipo e spesso - non sono ciò che apprezzo come responsabile dell'integrazione della mia azienda . I problema git rebase, git merge, git diff, e git applymolto più spesso in quel ruolo di git addo git commit. Strumenti come rebasemi permettono di trasformare il codice che mi viene dato da qualcosa che funziona in qualcosa che può essere mantenuto.

I commit illogici o vaghi non sono utili, ma sono peccaminosamente facili da scrivere in modo organico, quando la preoccupazione principale è far funzionare il codice, non distribuirlo ad altri. Si impegna Case 15: Fixed a problemo Refactored <cranky legacy feature>mi fa rabbrividire, anche quando li scrivo. Nessuno, tuttavia, induce la rabbia di blackout come i commit "incrementali". Considera questo ramo dell'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 cattive. È come DVCS progettato per il Dr. Faustus. Ti darò il controllo della fonte semplice e veloce. Mi dai l'anima del tuo manutentore del codice. Tutti gli impegni pigri sono atti egoistici. Molti di noi li scrivono, ma dobbiamo anche noi stessi al nostro futuro una storia logica, replicabile, debuggabile. Non possiamo farlo senza un modo rebase.

Per quanto riguarda gli esperimenti falliti, perché non descriverli nei nostri messaggi di commit (di recente incontaminati)? Tra un anno non ho bisogno di uno snippet semifinito. Voglio solo un resoconto del tentativo interrotto e forse una breve spiegazione se penso di essere abbastanza sciocco da riprovare. Esistono molti flussi di lavoro di successo nel mondo, ma faccio fatica a pensare a qualsiasi motivo per cui consenzierei consapevolmente codice non funzionante a una base di codice di produzione.

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

Personalmente trovo molto utile riformulare un ramo di funzionalità locale rispetto al 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 unione ecc. Prima di fondere effettivamente.

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