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
переименовать одну и ту же папку, которую вам придется разрешать, но кроме этого вы должны быть в порядке.