Разрешение конфликта слияния, объединенного как в исходной, так и в целевой ветке

У меня есть две ветки:
Ветвь "dev"
Ветвь "prod"

«dev» — это место, где объединены все функции, «prod» — это производственная ветвь. Перед выпуском новых выпусков «dev» объединяется с «prod», и из него создается сборка выпуска.

В ветке "prod" есть определенные вещи, такие как реклама, которые мне не нужны в ветке "dev".

Сегодня при слиянии «dev» с «prod» у меня возник конфликт слияния. Разрешение слияния изменило как мою исходную ветку «dev», так и целевую ветку «prod». Таким образом, у меня есть много частей кода от цели к источнику, которые мне не нужны.

Каков наилучший способ сохранить изменения в «prod», но отменить их в «dev»? Спасибо.


git merge git-merge-conflict
person SayantanRC    schedule 02.03.2020    source источник
comment
Разрешение конфликтов не меняет ни одной ветки. Ничто не изменяет существующую фиксацию, так как это невозможно. Добавление нового фиксации в текущую ветку делает именно это: добавляет новую фиксацию в текущую ветку.   -  person torek    schedule 02.03.2020
comment
Я подозреваю, что вы спотыкаетесь о разницу между файлами, которые вы видите и редактируете в своем рабочем дереве, и файлами, которые находятся в каждом коммите. Помните, что имена ветвей просто содержат хэш-идентификаторы существующих коммитов, а процесс добавления нового коммита состоит из (1) создания нового коммита таким, чтобы его родителем (родителями) были существующие коммиты, а затем (2) написания хэш-идентификатор нового коммита в имя текущей ветки, чтобы новый коммит теперь содержался в ветке. Слияние создает новую фиксацию (как обычно, со снимком) с двумя родителями, так что обе цепочки коммитов становятся доступными.   -  person torek    schedule 02.03.2020
comment
Практический метод применения изменения к исторической фиксации, а затем слияния этого изменения с обеими ветвями см. в Gem. Ответ Тейлора, но вместо этого рассмотрите многочастное эссе Рэймонда Чена .   -  person torek    schedule 02.03.2020

Ответы (1)


arrow_upward
0
arrow_downward

Когда вы решаете, что вы на самом деле хотите сделать, лучше всего сначала отмотать назад и попробовать еще раз, но вы можете сделать это только в том случае, если вы еще не отправили изменения или никто впоследствии не отправил изменения (и у вас достаточно администратора). права). Если вы хорошо попросите, люди, возможно, смогут снова отправить свои изменения после того, как вы очистили.

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

По сути, сначала выполните рефакторинг обеих баз кода, чтобы они были совместимы с фактическим изменением функции, получите его, а затем получите отправленное изменение функции.

Вероятно, это предполагает наличие до 4 ветвей:

  • Разовый разработчик для рефакторинга
  • Разовый продукт для рефакторинга, где вы исправите рефакторинг против рекламы
  • Секунда от рефакторинга разработчика, содержащего эту функцию
  • Секунда после рефакторинга версии, которая получит эту функцию, и вы не ожидаете проблем при слиянии с ней.

Надеюсь, вы сможете сохранить изменения достаточно чистыми, чтобы затем объединить каждую из этих ветвей по очереди и отправить их.

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

person Gem Taylor    schedule 02.03.2020