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

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

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

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

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

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

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

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

3 ответов


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

рекурсивные

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

осьминог

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

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

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

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

series of recursive merges

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

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

octopus merge

наша

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

это сохраняет историю ветви без каких-либо последствий ветви.

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

поддерева

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


на самом деле только две стратегии, которые вы хотели бы выбрать несколько наша Если вы хотите отказаться от изменений, внесенных ветку, но держать ветку в истории, и поддерева Если вы объединяете независимый проект в подкаталог superproject (например, "Git-gui" в репозитории "git").

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


" Resolve "vs" рекурсивная " стратегия слияния

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

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

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

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

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