Когда бы вы использовали разные стратегии git merge?

Question

На странице руководства git-merge вы можете использовать несколько стратегий слияния.

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

• рекурсивный - Это может разрешить только две головы, используя 3-х сторонний алгоритм слияния. Если для трехстороннего слияния можно использовать несколько общих предков, оно создает объединенное дерево общих предков и использует его в качестве ссылочного дерева для трехстороннего слияния. Сообщается, что это приводит к меньшему количеству конфликтов слияния, не вызывая слияний в результате тестов, выполненных на реальных коммитах слияния, взятых из истории разработки ядра Linux 2.6. Кроме того, это может обнаруживать и обрабатывать слияния, связанные с переименованием. Это стратегия слияния по умолчанию при извлечении или слиянии одной ветви.

• осьминог - Это решает более чем двухголовый случай, но отказывается выполнять сложное слияние, которое требует ручного разрешения. Он в первую очередь предназначен для объединения глав веток тем. Это стратегия слияния по умолчанию при вытягивании или объединении нескольких ветвей.

• наши - Это разрешает любое количество головок, но результатом слияния всегда является текущая головка. Он предназначен для замены старой истории развития боковых веток.

• поддерево - Это модифицированная рекурсивная стратегия. При объединении деревьев A и B, если B соответствует поддереву A, B сначала корректируется, чтобы соответствовать древовидной структуре A, вместо того, чтобы читать деревья на том же уровне. Эта настройка также выполняется для дерева общего предка.

Когда я должен указать что-то отличное от значения по умолчанию? Для каких сценариев лучше всего подойдет?

Answer 1

Я не знаком с решимостью, но я использовал другие:

Рекурсивный

Рекурсивный - значение по умолчанию для слияний без ускоренной перемотки вперед. Мы все знакомы с этим.

Octopus

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

Ветвь осьминога объединяет несколько голов в один коммит, если он может делать это чисто.

Для иллюстрации представьте, что у вас есть проект, в котором есть мастер, а затем три ветви для объединения (назовите их a, b и c).

Серия рекурсивных слияний выглядела бы так (обратите внимание, что первое слияние было ускоренным, поскольку я не вызывал рекурсию):

Однако, одиночное слияние осьминога будет выглядеть так:

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...

Ours

Наши == Я хочу добавить другую голову, но выбросить все изменения, которые вносит эта голова.

Сохраняет историю ветви без каких-либо эффектов ветви.

(Чтение: Он даже не рассматривал изменения между этими ветвями. Ветви просто объединяются, и к файлам ничего не делается. Если вы хотите объединиться в другой ветке, и каждый раз возникает вопрос "наш файл" версию или их версию "вы можете использовать git merge -X ours)

Subtree

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

Answer 2

На самом деле вы можете выбрать только две стратегии: наша , если вы хотите отказаться от изменений, внесенных ветвью, но сохранить ветку в истории, и поддерево , если вы объединяете независимый проект в подкаталог суперпроекта (например, «git-gui» в репозитории «git»).

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

Answer 3

Стратегия слияния "Resolve" и "Recursive"

Рекурсивная текущая стратегия с двумя головками по умолчанию, но после некоторого поиска я наконец нашел некоторую информацию о стратегии слияния "resolve".

Взято из книги О'Рейли Контроль версий с помощью Git ( Amazon ) (перефразировано):

Изначально "resol" была стратегией по умолчанию для слияний Git.

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

Я успешно объединил деревья, используя «resolv», который не удался с рекурсивной стратегией по умолчанию. Я получал fatal: git write-tree failed to write a tree ошибок, и благодаря этому сообщению в блоге ( mirror ) я попытался "-s решить", что сработало. Я до сих пор не совсем уверен, почему ... но я думаю, что это произошло потому, что у меня были дублирующиеся изменения в обоих деревьях, и я решил "пропустить" их правильно.