it-swarm.com.ru

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

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

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

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

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

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

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

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

409
Otto

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

Рекурсивный

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

Осьминог

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

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

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

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

series of recursive merges

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

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

octopus merge

Наш

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

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

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

Subtree

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

296
Dustin

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

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

46
Jakub Narębski

"Решить" против "Рекурсивной" стратегии слияния

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

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

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

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

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

21
thaddeusmt