Git połączyć i zachować oddzielne?

Question

Czy istnieje sposób na aktualizację oddziału bocznego z informacjami od innego (wzorca lub innego), a następnie kontynuowanie? Podobnie jak w przypadku rebase, ale zachowując stare dane?

oryginalny:

A---B---C---G---H master 
    \   
     D---E---F branchA 

Wynik:

A---B---C---G---H---L master 
    \   \ 
     D---E---F---J---K branchA 

Takie że branchA dostaje informacje z dopuszcza C, G, i H, (Commit J jest scalenie), takie, które dokonują K jest jeszcze gałąź boczna (i przyszłe zatwierdzenie L nadal znajduje się w stanie nadrzędnym), ale czy zaktualizowane informacje pochodzą od wzorca?

nie chcę zrobić rebase, bo to by skończyć z:

A---B---C---G---H---L master 
       \ 
        D'---E'---F'---K branchA 

„Tworzenie nowych wersji” D, E i F, jakby wydarzyło się na górze zamiast H B i Problem polega na tym, że commits C i E to zmiana nazwy folderu kluczy w repozytorium i chcę je zwinąć razem:, bez łączenia innych aktualizacji funkcji z branchA. Rebasing oznacza, że ​​H używa nowej nazwy folderu, D 'tworzy starą nazwę folderu, a E' usuwa ją ponownie, co nie jest najczystsze.

Chodzi o to, że chcę, aby ta nazwa zmieniła się w przeszłości (C i E) i przestać ją przenosić. Czy to ma sens? Czy patrzę na to wstecz? Czy powinienem po prostu poradzić sobie z nieuporządkowanym rebase "name, rename", dopóki gałąź nie zostanie scalona?

Answer 1

Jeśli historia sięga aż do H lub L na pana i F na branchA (to jest, J i K nie istnieją jeszcze), to tak, po prostu sprawdzić gałęzi i scalania:

git checkout branchA 
git merge H # Use H's commit identifier if it's not the tip of master 

Spowoduje to scalenie zmian w branchA i nie będzie w ogóle przeszkadzać gałęzi master.

Jeśli utworzono już popełnić K i chcesz wstawić seryjnej między nim i F, a następnie tam trochę więcej do zrobienia:

git checkout -b temp F # Create a new branch at commit F 
git merge H    # Merge from commit H into the new branch 
git cherry-pick K  # Apply the K commit to the merged commit 

# And the rest simply replaces the temp branch with branchA 
git checkout branchA 
git reset --hard temp 
git branch -d temp 

W obu przypadkach, jeśli później scalić w obu kierunkach , commit H będzie najbliższym wspólnym przodkiem obu gałęzi historii, więc przyszłe scalenia nie będą wyglądały poza tym zatwierdzeniem (lub przeszłym J do F), gdy decydują, jak się scalić.

Answer 2

Prosty git merge master na branchA powinien zrobić (lub git merge H gdzie H oznacza H na popełnić-ref jeśli H nie jest ostatni na mistrza).

Pojawią się konflikty, jeśli zarówno C jak i E zmienią nazwę tego samego folderu, który będzie musiał rozwiązać, ale poza tym powinieneś być w porządku.