Интерактивная перебазировка объединенной ветки

Я использую git и дохожу до такого состояния:

      X --- Y --------- M1 -------- M2 (my-feature)
     /                 /           /
    /                 /           /
   a --- b --- c --- d --- e --- f (stable)

Это происходит, когда мы работаем над веткой my-feature больше суток. M1 и M2 объединяются из стабильной ветки в функциональную ветку. M1 и M2 могли иметь объединенные конфликты, которые были разрешены. Вся идея слияния стабильной ветки с функциональной веткой состоит в том, чтобы как можно раньше разрешить конфликты.

Как только функция будет завершена, мы хотим перебазировать ветку функции на один или два коммита.

Проблема в том, что когда мы делаем интерактивную перебазировку, git показывает нам те же конфликты слияния, которые мы уже решаем во время слияний M1 и M2.

Есть ли способ заставить git повторно использовать решение о слиянии, которое мы уже приняли в M1 и M2?


person Ido Ran    schedule 08.07.2012    source источник
comment
возможный дубликат git rebase после предыдущего слияния git   -  person Ciro Santilli 新疆再教育营六四事件ۍ    schedule 12.01.2014


Ответы (4)


Если конфликты слияния идентичны, это идеальный вариант использования git rerere, одной из самых полезных (хотя и менее известных) команд в git. Из справочных страниц:

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

Эта команда помогает разработчику в этом процессе, записывая конфликтующие результаты автоматического слияния и соответствующие результаты ручного разрешения при первоначальном ручном объединении и применяя ранее записанные ручные разрешения к соответствующим результатам автоматического слияния.

git rerere ведет учет ваших разрешений конфликтов и автоматически применяет их при возникновении такого же конфликта в git merge, git rebase или git commit (при совершении слияния). Скотт Чакон поместил здесь несколько замечательных примеров и справочную страницу также стоит прочитать.

Вы можете включить git rerere в merge и rebase, введя эту команду:

git config --global rerere.enabled true

Снимите флаг --global, если вы хотите, чтобы опция была включена только для одного репозитория.

person Christopher    schedule 08.07.2012
comment
Спасибо. Я читал о rerere, но до сих пор не использовал его. - person Ido Ran; 08.07.2012
comment
На самом деле у меня есть один вопрос по этому поводу: мы работаем в команде, когда кто-то другой выполняет конфликт слияния, каталог rr-cache будет на их машине. Получает ли он копию в основной репозиторий? Или я могу поделиться данными rr-cache между командой? - person Ido Ran; 08.07.2012
comment
rr-cache не передается через удаленный доступ, но если вы делитесь фактическим каталогом rr-cache между репозиториями другим способом, он должен работать. Вот хороший ответ о том, как сделать сам rr-cache репозиторием с символической ссылкой: stackoverflow.com/a/5410923/877115. - person Christopher; 09.07.2012

Явный способ превратить ветку функции feature в новую ветку feature-one-commit с помощью одной фиксации:

git checkout -b feature-one-commit \
"$(git commit-tree HEAD^{tree} -m "Commit message" -p master)"    
person Ciro Santilli 新疆再教育营六四事件ۍ    schedule 11.01.2014
comment
Это было самое простое решение для меня, и я также узнал о git-commit-tree. . Git действительно глубокая кроличья нора, хех. - person Ainar-G; 30.12.2020

Вы всегда можете заставить его использовать флаг -f

person chrisbulmer    schedule 08.07.2012

person    schedule
comment
Я уже пытался сохранить слияние, но моя ошибка, похоже, в том, что я помечаю фиксацию слияния как сквош. Теперь я сделал это снова и пометил только фиксацию после M2 как сквош. - person Ido Ran; 08.07.2012
comment
Будьте осторожны с этой комбинацией флагов при перебазировании. Это может привести к нелогичным результатам: article.gmane.org/gmane.comp. контроль версий.git/148059 - person Christopher; 08.07.2012
comment
Да, я читал, что совместное использование -i и -p может быть опасным. Я никогда не переупорядочиваю коммиты, а только выбираю, что выбрать, а что раздавить. Я заметил, что если я раздавлю фиксацию сразу после слияния, это заставит git воссоздать объединенную фиксацию и исправить историю строк фиксации. - person Ido Ran; 08.07.2012
comment
Есть ли обходной путь для редактирования старой фиксации при сохранении слияний? - person lkraav; 26.02.2013
comment
Я не думаю, что это решает проблему ОП, и я не могу быть уверен, потому что нет объяснения. - person hmijail mourns resignees; 23.06.2016