Хорошо ... звучит так, что development - это долгоживущая ветвь, представляющая предыдущий выпуск (и) - очень похоже на master в gitflow.
И похоже, что v1.0 - этодолгоживущая ветвь, в которой вы собираете следующий выпуск, очень похоже на develop в gitflow.
И данная локальная ветвь может быть похожа на ветвь функций (в этом случае вы объедините ее с v1.0) или как исправление (в этом случае вы объедините его с v1.0 и development).Странно то, что вы, кажется, всегда создаете локальные ветви, чтобы они могли быть объединены с обоими.(Так что вы не знаете, во время создания ветки, будете ли вы сливаться с development? Потому что, если это не так, каждая ветвь «запускается заново» на базе слияния кажется, что она имеет некоторые ненужные затраты на разрешение слияния... но я отвлекся.)
Давайте рассмотрим ваш сценарий с картинками.Вы начинаете с
A -- x <--(development)
\
Z <--(v1.0)
и создаете локальную ветку
A -- x <--(development)
|\
| Z <--(v1.0)
\
B -- C <--(feature)
, а ваш коллега создает локальную ветку
A -- x <--(development)
|\
| x -- O <--(hotfix)
|\
| Z <--(v1.0)
\
B -- C <--(feature)
(потерпите меня здесь; яПоймите, что никогда не может быть одного репо со всеми этими ветками, но давайте все равно посмотрим на «большую картину» ...)
Так что ваш коллега сливается с обеими долгоживущими ветвями
A -- x -- M <--(development)
|\ /
| x --- O <--(hotfix)
|\ \
| Z ----- M <--(v1.0)
\
B -- C <--(feature)
Обратите внимание, что с этого момента O является базой слияния для development и v1.0.Но ваша ветвь была создана, когда база слияния была A, поэтому теперь мы подошли к вашему вопросу: как получить hotfix в вашу ветку.
К настоящему времени hotfix является неотъемлемой частью общей историитак что вы, вероятно, не хотите делать что-либо, что переписывает и / или дублирует изменения из его коммитов.
Скорее всего, вы не хотите сливать v1.0 в свою ветку, потому что микширование Z вкажется, что ваша ветвь работает против структуры создания ветви на базе слияния.
Так что вы действительно просто хотите объединить O в свою ветку.Теперь давайте немного переключимся и посмотрим, как может выглядеть ваше локальное репо, если я буду понимать ваш термин «локальные филиалы» буквально (то есть у вас нет ветви hotfix):
A -- x -- M <--(development)
|\ /
| x --- O
|\ \
| Z ----- M <--(v1.0)
\
B -- C <--(feature)
Теперь, учитывая, что feature является также локальным (присутствует только в вашем репо), один из вариантов - перенести его в новую базу слияния - и похоже, что он остается в духе вашего рабочего процесса.
git rebase $(git merge-base development v1.0) feature
даст вам
A -- x -- M <--(development)
|\ /
| x --- O -- B' -- C' <--(feature)
\ \
Z ----- M <--(v1.0)
В этот момент B' и C' являются непроверенными состояниями кода.В идеале вы должны протестировать оба из них и решить любые проблемы (хотя, если в B' есть проблемы, которые легче сказать, чем сделать), чтобы у вас все еще была чистая история.
Другой вариант, которыйпозволит избежать проблемы «непроверенных коммитов», но создать более «грязную» (хотя и, возможно, более точную) историю - это просто слить базу слияния в вашу ветку.
git checkout feature
git merge $(git merge-base v1.0 development)
, которая дает вам что-то вроде
A -- x -- M <--(development)
|\ /
| x --- O -----------
|\ \ \
| Z ----- M <--(v1.0) \
\ \
B -- C -------------- M <--(feature)
Что, после долгих слов сказать «почему», означает, что мы сделали по сути то, что вы уже сделали, за исключением пропуска этапа создания ветви для слияния, поскольку мы можем просто обратиться к базе слияниянапрямую.
И это имеет смысл.Вы уже выяснили, какие изменения нужно объединить с вашей веткой - вы на самом деле не хотите изменить коммит, который вы объединяете.Поэтому лучшее, что мы можем сделать, - это найти более простой способ обратиться к этим изменениям.