Если конфликт возникает в двоичных или любых нетекстовых файлах, которые не могут быть разрешены с помощью текстового редактора, я должен использовать git checkout --theirs или git checkout --ours вместо ...
Это не обязательно так.Как и в случае с обычными текстовыми файлами, где иногда правильное разрешение фактически является объединенным изменением, правильное разрешение некоторых двоичных файлов может быть объединенным изменением.Просто Git не может сделать это за вас.Единственный способ сделать это правильно - это найти исходный файл или файлы и какой-то переводчик исходного кода в двоичный.Вам может потребоваться объединить исходные изменения, скомпилировать / преобразовать результат в новый, третий двоичный файл и использовать его.
Тем не менее, на этот вопрос есть ответ.Это может быть бессмысленно изучать и запоминать.
Но, если я просто ничего не делаю, добавьте эти незакрепленные двоичные файлы непосредственно в область подготовки ...
Что git add выполняет копирование всего, что находится в рабочем дереве, в индексную / промежуточную область в нулевом слоте, удаляя все записи более высокого уровня.Во время конфликта у вас есть три разных двоичных файла в области индекса / промежуточного хранения, но с использованием слотов 1 (база слияния), 2 (наш) и 3 (их).
Следовательно, это просто означает Скопируйте файл рабочего дерева в нулевой слот и удалите записи в слотах 1, 2 и 3. Так что вопрос такой же, как:
Что Git оставляет в рабочем деревев случае конфликта в двоичном файле?
Ответ на этот вопрос содержится в git merge документации и документации gitattributes .Это затрудняет чтение.
Первый говорит о стратегиях recursive и resolve, что есть дополнительные аргументы, которые влияют на результат.Эти дополнительные аргументы являются аргументами -X ours и -X theirs, что означает:
ours
Этот параметр заставляет конфликтующие фрагменты автоматически разрешаться автоматическиотдавая предпочтение нашей версии.Изменения в другом дереве, которые не конфликтуют с нашей стороной, отражаются на результате слияния.Для бинарного файла все содержимое взято с нашей стороны.
...
их
Это противоположно нашим; обратите внимание, что, в отличие от наших , нет их стратегия слияния, чтобы спутать эту опцию слияния с.
Документация gitattributes добавляет это:
Выполнение трех-way merge
...
Атрибут merge влияет на способ объединения трех версий файла, когда необходимо объединение на уровне файла ...
а затем продолжает говорить, что большинство из них «[k] выдают версию из вашей ветви в рабочем дереве».Таким образом, в целом соответствует рабочему дереву index-slot-2, которое вы можете проверить, выполнив git checkout-index --temp --stage=2 test.bin и сравнив полученный файл с test.bin.
Не ясно, так ли этопереопределение атрибутов -X theirs;вам придется проверить это, если вы установите свои собственные атрибуты merge и используете -X theirs, сравнивая то, что находится в рабочем дереве, с тем, что находится в слотах индекса 2 и 3.
В целом, однако,большинство подходов в основном оставляют «нашу» версию в рабочем дереве.Если это уместно, вы можете использовать git add, чтобы скопировать версию рабочего дерева обратно в нулевой слот и стереть слоты 1-3, помечая файл как разрешенный.Просто убедитесь, что если вы использовали -X theirs и / или какой-то интересный параметр merge, то вы знаете, что делаете, и дважды проверили все.
(Ваша лучшая ставка, конечно,чтобы избежать слияния бинарных файлов таким способом.)