Ramo git rebase con figli uniti

Question

Oggi ho affrontato un problema. Il mio compagno di squadra ha creato un ramo dal master. Ha sviluppato una funzione in questo ramo e successivamente ha sviluppato due sottofunzionalità nei rami della sottofunzione. Alla fine fece due commit di refactoring dell'intera faccenda. Quindi ...

 C--D E--F    | subfeatures 
    / \/ \ 
    B------M1------M2--G--H | feature 
/
A-------------------K  | master 

Di solito ci REBASE caratteristica rami prima fusione no-fast-forward in master. Ma ovviamente questo rebase fallisce. ramo di caratteristica Ribasato divenne assomigliare:

 B'--C'--D'--E'--F'--G'--H' 
    /
A--K 

Naturalmente puntatori di C & D è diventato sbagliato così ho anche ottenere due rami caratteristica secondaria cresce 'dal air'. Capisco come risolverlo se i rami di sottofunzione non sono stati uniti in funzionalità, ma in questo momento ero confuso. Ho selezionato tutto in un ramo di recupero basato su rebased e unito di nuovo tutto. È qui un modo più semplice per farlo?

Answer 1

Nota che è necessario un git1.7.6 + per git rebase --preserve-merges per funzionare correttamente.

• un rebase --preserve-merges --onto non ha funzionato prima (" git rebase --preserve-merges --onto doesn't preserve merges ")
• un rebase --preserve-merges ebbe figli in qualche esempio:
  • vedere this thread, quando entrambi i lati della fusione vengono riprodotti)
  • " Git: Rebasing Merge Commits "(post dal Alexandru Pasca)

Per farla breve: hai appena completato un'unione e qualcuno ha inviato un commit prima che tu riuscissi a spingere il tuo. La soluzione è rendere git consapevole della fusione che hai fatto.

git rebase --preserve-merges <upstream> 

o

git rebase -p <upstream> 

Ma c'è un problema, se la stampa avesse conflitti che avete risolto non saranno raccolti dalla macchina rebase.
E si finirà per risolvere i conflitti di nuovo ... almeno questo è il caso con la versione git 1.7.5.4

(Che sarebbe chiamata per git rerere)

Answer 2

Hai cherrypick ogni commit uno per uno a mano?

Basta eseguire git rebase -i master feature e riscrivere la cronologia come ti pare.