Git сливаются и сохраняются отдельно?

Есть ли способ обновить боковую ветвь информацией от другой (мастер или другой), а затем продолжить? Как rebase, но сохраняя старые данные там?

Оригинал:

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

Результат:

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

Таким образом, branchA получает информацию от коммитов C, G и H (Commit J - это слияние), так что commit K по-прежнему является боковой ветвью (и будущий commit L все еще находится на master), но имеет обновленная информация от мастера?

Я не хочу делать rebase, потому что это закончится тем, что:

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

Создание "новых версий" D, E и F, как если бы они выполнялись поверх H вместо B, а проблема заключалась в том, что C и E - это переименование ключевой папки в репо, и я хочу свернуть их вместе, не добавляя еще никаких обновлений функций из branchA. С помощью метода переустановки H использует новое имя папки, D 'создает имя старой папки, а E' удаляет ее снова, что не является самым чистым.

Суть в том, что я хочу, чтобы эта папка переименовала (C и E) в прошлом и перестала ее переносить. Это имеет смысл? Я смотрю на это назад? Или мне просто нужно разобраться с беспорядочным подзапросом "имя, переименовать", пока ветка не будет слита?

Ответ 1

Если ваша история поднимается до H или L на master и F на ветке A (то есть J и K еще не существуют), тогда да, просто проверьте ветвь A и слейте:

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

Это объединит изменения в branchA и не повредит главную ветвь.

Если вы уже создали commit K, и вы хотите вставить слияние между ним и F, то еще немного работы:

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

В обоих случаях, если вы позже объединитесь в любом направлении, commit H станет ближайшим общим предком обеих ветвей истории, и поэтому будущие слияния не будут проходить мимо этого фиксации (или от J до F) при принятии решения о том, как слияния.

Ответ 2

Простой git merge master на branchA должен делать (или git merge H, где H является H commit-ref, если H не является последним на master).

Будут конфликты, если оба C и E переименовать одну и ту же папку, которую вам придется разрешать, но кроме этого вы должны быть в порядке.