Git: rebasing su un refactoring che interessa il ramo di rebase target

Nessuno

L'opzione 1 suona come un sacco di lavoro non necessario. Perché non vuoi nascondere il fatto che questo codice è stato scritto prima del refactoring di dev ?

Un altro svantaggio con l'opzione 2: dopo il rebase avrai molti commit eventualmente non lavorativi prima del commit del 2o refactoring. Questo ti darà problemi quando bisecerai da quando quei commit potrebbero essere non testabili.

Opzione 3: Unisci dev branch in feature branch.

• Pro: otterrai il rectoring da dev e potresti refactoring il resto del ramo feature nell'unione per ottenere un progetto funzionante.
• Pro: nessun commit non viene verificato. (supponendo che i commit già effettuati siano stati testati).
• Contro: non potrai continuare la rebasazione su dev branch.

Sembra che la rivoluzione del git abbia creato una nuova nevrosi chiamata ansietà della storia del commit. Nessuno oltre a te importa ciò che è nei tuoi impegni. Basta fare il lavoro nel modo più efficiente possibile. Quindi puoi utilizzare il tempo che hai salvato per correggere un bug o aggiungere una funzionalità.

Non sei sicuro del motivo per cui dovresti eseguire un rebase -i. Vorrei solo fare un rebase e correggere i problemi non appena entrano in funzione.

Trovo che riparare uno e uno sia più facile che correggere ogni errore dopo le parole. Puoi anche assicurarti, tra ogni commit, che i tuoi test siano ancora eseguiti (dato che hai dei test).

Infine, trovo che 2) sia problematico se prevedi di continuare a rebasing in futuro, se la tua funzione non è ancora stata eseguita. Rifondare in un'unione non è davvero qualcosa che farei se potessi evitarlo. Se la funzione è terminata e non ti interessa molto della cronologia, puoi semplicemente unire.

Conclusione: Vorrei rebase personalmente, senza il -i, e correggere ogni commit. La ragione è che trovo abbastanza utile un registro ordinato e spesso sento che è il modo più semplice per farlo.

EDIT: Con il tuo esempio, direi che dipende. Se ci sono una quantità enorme di commit, hai chiamato functionA un sacco di volte, ed è fondamentalmente un enorme problema rebase a ogni singolo commit, probabilmente ricorreremo a fare solo una search-replace in un singolo commit. Se avessi saputo che c'erano solo pochi punti e che la rifocalizzazione sarebbe stata facile, avrei rebase.

Dato che chiedi, immagino che il primo sia la situazione in cui ti trovi, e avrei comunque pensato a quanto dolore sarà per ripulire il registro.

Fondamentalmente, non dovresti usare i rami git per i rami di funzionalità.

link

link

In effetti vedo che questo è il motivo decisivo per cui Feature Branching è una cattiva idea. Una volta che una squadra ha paura di rifattarsi per mantenere il proprio codice in buona salute, è in una spirale discendente senza una fine carina.

Nel testo citato, Martin Fowler usa "Feature Branching" per indicare specificamente "l'uso della ramificazione di dvcs per gestire lo sviluppo di feature di grandi dimensioni in un modo in cui un ramo di dvcs esegue il mapping su una caratteristica". Che molte persone fanno. Alcune di queste persone si trovano in un ambiente in cui non hanno mai realmente bisogno di refactoring, alcune non l'hanno fatto abbastanza a lungo da colpire i problemi, alcuni hanno sviluppato strumenti o procedure su git per aggirare i problemi ( link ), mentre altri stanno semplicemente negando quanto problemi causano loro.

Il fatto è che, proprio perché un concetto astratto e una caratteristica di uno strumento hanno lo stesso nome, non li rendono una buona corrispondenza reciproca. Come stai scoprendo, non c'è davvero un buon modo per utilizzare i due insieme, solo una varietà di modi meno cattivi.

Quindi, supponendo che tu abbia davvero bisogno di branch di funzionalità, quindi guarda attraverso le funzionalità il tuo tooling e il supporto della piattaforma e trova una corrispondenza migliore.

Rimanere con git, usare le forche e le richieste di pull è una strategia sempre più comune:

link

Nel peggiore dei casi, anche l'umile dichiarazione if [config-setting] (nota come 'funzionalità di attivazione / disattivazione') è molto probabile che sia un risparmio di tempo e un aumento di qualità rispetto a dove ti trovi ora.