Что представляет собой конфликт слияния в Git?

Как git определяет, что конкретное слияние имеет конфликт и что такое конфликт?

Мое предположение получило бы что-то вроде этого: если два коммита, которые были объединены, имеют общий родительский фиксатор, и если они оба изменили строку X от того, что у родителя, то конфликт.

Что усложняет мое понимание:

"Изменение строки X" может означать замену его несколькими новыми строками и все еще отображаться как один конфликт (версия A имеет одну строку, а версия B имеет эти 5 строк или что-то еще)
Если вы ввели строки в один из коммитов, алгоритм с ошибкой подумал бы, что строки all были изменены: строка 30 теперь имеет прежнее содержимое строки 25, 31 имеет прежнее содержимое 26 и т.д. Но git может сказать, что те же, и я не знаю, как это сделать.

Может кто-нибудь объяснить, как это работает, или указать мне ссылку, которая делает?

Ответ 1

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

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

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

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

Ответ 2

Я не думаю, что алгоритм слияния имеет что-то особенное с Git: это классический трехсторонний алгоритм слияния (а не Codeville one), который можно использовать с несколькими стратегиями (по умолчанию: рекурсия или разрешение или осьминог), Результатом является довольно простой процесс слияния, который описан здесь.
Любая потребность в визуализации затем делегируется сторонним средствам слияния/разметки.

Ответ 3

Перейдите к пункту HOW CONFLICTS ARE PRESENTED на этой странице .

LE: нет реальной документации для случаев конфликтов и маркеров конфликтов конфликтов, и поскольку я получаю комментарии в комментариях здесь, здесь указатели исходного кода, которые ведут где-то близко к тем, какие стратегии git следуют по порядку для достижения конфликтного состояния. Файл merge-recursive.c, найдите строку "CONFLICT. Делая это, мы можем легко узнать, что на самом деле существует несколько примеров конфликтов:

CONFLICT (переименовать/переименовать)
КОНФЛИКТ (контент)
CONFLICT (переименование/каталог)
CONFLICT (переименование/удаление)
CONFLICT (переименовать/добавить)
CONFLICT (удалить/изменить)
... ans so on

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

@Wim Coenen да, это тоже зависит от стратегий слияния, но как конфликты представлены, дает гораздо больше понимания. Затем вы можете прочитать стратегии слияния, если вы спросите меня, но вы все еще сомневаетесь.