Riorganizzazione di rami argomento dipendenti

Question

Uso in git molti rami di argomenti locali e, a volte, con dipendenze tra rami argomento che causano problemi di rebase. Ad esempio, con una struttura come:

master ---> featureA ---> featureB 
        \--> featureC 

If master modifiche e ottengo (e risolvere) i conflitti quando rebasing featureA, poi dopo rebasing featureB sul featureA innesca gli stessi conflitti (e quelli a volte entusiasmanti nuovi pure) perché prova a riapplicare le patch dal ramo featureA. Supponendo che le patch effettive tra featureA e featureB si applichino in modo pulito se selezionate, esiste un modo per eseguire un rebase in questa situazione con più o meno lo stesso effetto del cherry-picking di tutti i commit tra featureA e featureB?

Answer 1

Dopo rebasing featureA, si può fare

git rebase --onto featureA oldFeatureA featureB 

assumendo oldFeatureA rappresenta il commit sulla punta della featureA prima di Ribasato esso (è possibile mantenere un altro ramo lì o basta ricordare l'hash commit).

Questo dovrebbe essere sostanzialmente la stessa di ciliegia-picking ogni commit tra A e B sulla versione ricalcolato di A.

Documentation on git-rebase (incluse alcune spiegazioni pittorici voti di ciò che accade durante alcune operazioni più complesse REBASE)

Answer 2

Per il futuro, se lavori con molte branche di argomenti interdipendenti, forse dovresti prendere in considerazione l'utilizzo di TopGit (README), uno strumento per gestire la coda di patch usando i rami di argomenti di Git, una patch per ramo; o in alternativa uno strumento per gestire più rami di argomento.

Vedere ad es. topgit Means Never Having to Wait for Reviews post del blog.