Big git merge - разделение разрешения по коммитам - PullRequest
Новая
       69

Big git merge - разделение разрешения по коммитам

2 голосов
/ 03 августа 2020

Допустим, у меня есть ветка core-master и core-client1, которые довольно долго разделились на go (> 2 месяца).

core-master используется нашим основным продуктом, и core-client1 был необходим для версии white label для клиента. Мы не могли объединиться до сих пор из-за графиков выпуска.

Теперь, когда это возможно, я объединяю изменения core-client1 обратно в core-master.

Я хотел бы "break «вверх» разрешения конфликтов в отдельные коммиты, чтобы их можно было просмотреть / PR отдельно и откатить отдельно при необходимости.

Но поскольку у меня остались конфликты - git не позволит мне зафиксировать некоторые из файлы.

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

Я искал «git частичное слияние», «git разделенное слияние», но нашел только информацию о выборе определенных коммитов из core-master, то есть не имеет значения в моем случае.

Есть ли способ сделать это?

1 Ответ

2 голосов
/ 03 августа 2020

Я попытаюсь описать стратегию, которую я использовал в похожей ситуации:

Некоторое время (несколько месяцев) у нас было две версии, живущие бок о бок: 

*--x--*--*--*--*--*--* <- master
    \
     A--B--C--D--E--F <- side-version  # the actual nr of commits was more like 100

Объединить side-version в master в один go было невозможно.

В итоге я решил слить по крупицам: 

# merging bit by bit :
*--x--*--*--*--*--*--* <- master
    \                 \
     \                 *-----*-----*--* <- fusion
      \               /     /     /  /
       --------------A--B--C--D--E--F <- side-version

Для простоты использования: I не фиксировал сразу master, я создал ветку fusion и зафиксировал слияние там.

В истории side-version я перечислил несколько ключевых коммитов (в нашем случае: я использовал коммитов, соответствующих выпущенным версиям), и начал объединять эти версии по одной.

Теперь, поскольку обе версии были действующими, в некоторых случаях ошибки, исправленные на side-version, также были исправлены на master, поэтому иногда «слияние» приводило к отбрасыванию содержимого side-version и сохранению версии на master.

Наличие отдельных точек в основном позволяло мне:

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

Выбор «ключевых коммитов» действительно зависит от вашей настройки:

  • у вас может быть только несколько коммитов на side-version, которые все описывают состояние, при котором ваш продукт запускается и тестируется. , и в этом случае слияние по одному вполне нормально,
  • у вас может быть какой-то способ четко определить, «здесь была добавлена ​​эта особая c особенность», «здесь эта ошибка была исправлена» , и используйте их,
  • вы можете произвольно разделить историю side-version на десять частей ...

В зависимости от ваших потребностей.

Выбор точек слияния также может быть изменен:

  • в моем случае абсурдная фиксация, в которой говорится, что «версия master в августе в сочетании с side-version в мае "
  • если у вас есть стимул стремиться к более реалистичным c слияниям, вы также можете определить« ключевые фиксации »на master: 
# an alternative strategy :
*--x---P--Q--R--S--T--U--V <- master
    \      \     \        \
     \   *--*--*--*--*--*--* <- fusion
      \ /     /     /  /
       A--B--C--D--E--F <- side-version

Слияние действительно заняло некоторое время (несколько дней), в течение которого ветвь master развивалась. Когда я достиг своего первого удовлетворительного состояния fusion, мне фактически пришлось объединить некоторые дополнительные функции и исправления, выпущенные master.

В нашем случае было приемлемо иметь историю объединенных коммитов; как только вы достигли удовлетворительного состояния для fusion, вы можете переписать его историю, чтобы разделить коммиты на несколько более значимых фрагментов ...

...