Почему 3-х стороннее слияние выгодно по сравнению с 2-х сторонним слиянием?


Википедия говорит, что 3-полосное слияние менее подвержено ошибкам, чем 2-полосное слияние, и часто не требует вмешательства пользователя. Почему так происходит?

пример, где 3-полосное слияние завершается успешно, а 2-полосное слияние завершается неудачно, был бы полезен.

4 108

4 ответа:

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

Если вы выполняете двустороннее слияние (другими словами, diff), инструмент может сравнить два файла и увидеть, что первая и последняя строки отличаются. Но откуда ему знать, что делать с этими различиями? Должна ли объединенная версия включить первую строку? Должна ли она включать последнюю строку?

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

этот слайд из презентации волей-неволей интересно:

slide image

основная логика трехстороннего инструмента слияния проста:

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

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

вы можете спросить, какое преимущество предлагает 3-полосное слияние по сравнению с 2-полосным слиянием. На самом деле, нет такой вещи, как двустороннее слияние, только инструменты, которые различают два файла и позволяют вам "сливаться", выбирая куски из одного файла или другой.
только 3-полосное слияние дает вам возможность узнать, является ли фрагмент изменением от источника и изменяет ли конфликт.

Я написал очень подробный пост об этом. В принципе, вы не можете отслеживать удаления/добавления с двусторонним, очень, очень непродуктивным.

трехстороннее слияние, где два набора изменений в один базовый файл объединяются по мере их применения, в отличие от применения одного, а затем слияния результата с другим.

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

файл a был изменен двумя людьми, один добавляет лося, один добавляет мышь.

#File a
    dog
    cat

#diff b, a
    dog
+++ mouse
    cat

#diff c, a
    dog
+++ moose
    cat

Теперь, если мы объединить наборы изменений, как мы их применяем, мы получим (3-way merge)

#diff b and c, a
    dog
+++ mouse
+++ moose
    cat

но если мы применим b, то посмотрите на изменение от b до c, это будет выглядеть так, как будто мы просто меняем 'u' на 'o' (двухстороннее слияние)

    #diff b, c
    dog
--- mouse
+++ moose
    cat