Разрешение конфликта Git с двоичными файлами

Вы должны разрешить конфликт вручную (скопировав файл), а затем зафиксировать файл (независимо от того, скопировали ли вы его или использовали локальную версию), как это

git commit -a -m "Fix merge conflict in test.foo"

Обычно Git выполняет автоматическую фиксацию после слияния, но когда он обнаруживает конфликты, которые не может решить сам по себе, он применяет все найденные патчи, а остальные оставляет вам на разрешение и фиксацию вручную. Запись в блоге Страница Git Merge Man, Ускоренный курс Git-SVN или это может пролить свет на то, как это должно работать.

Редактировать: См. Сообщение ниже, на самом деле вам не нужно копировать файлы самостоятельно, но можно использовать

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

чтобы выбрать нужную версию файла. Копирование / редактирование файла необходимо только в том случае, если вы хотите смешать обе версии.

Отметьте, пожалуйста, ответ мипади как правильный.

Я столкнулся с аналогичной проблемой (хотел вытащить фиксацию, которая включала некоторые двоичные файлы, которые вызывали конфликты при слиянии), но наткнулся на другое решение, которое можно сделать полностью с помощью git (т.е. без необходимости вручную копировать файлы). Я решил, что включу его здесь, чтобы, по крайней мере, я мог вспомнить его в следующий раз, когда он мне понадобится. :) Шаги выглядят так:

% git fetch

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

% git checkout FETCH_HEAD stuff/to/update

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

Вы также можете решить эту проблему с помощью

git mergetool

что заставляет git создавать локальные копии конфликтующего двоичного файла и запускать на них ваш редактор по умолчанию:

• {conflicted}.HEAD
• {conflicted}
• {conflicted}.REMOTE

Очевидно, вы не можете с пользой редактировать двоичные файлы в текстовом редакторе. Вместо этого вы копируете новый файл {conflicted}.REMOTE поверх {conflicted}, не закрывая редактор. Затем, когда вы закроете редактор, git увидит, что недекорированная рабочая копия была изменена, и ваш конфликт слияния разрешен обычным способом.

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

git commit -a

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

git checkout otherbranch theconflictedfile
git commit -a

Объяснил более подробно

git checkout принимает вариант --ours или --theirs для подобных случаев. Итак, если у вас есть конфликт слияния, и вы знаете, что вам просто нужен файл из ветки, в которую вы сливаете, вы можете сделать:

$ git checkout --theirs -- path/to/conflicted-file.txt

чтобы использовать эту версию файла. Точно так же, если вы знаете, что хотите свою версию (а не ту, которая объединяется), вы можете использовать

$ git checkout --ours -- path/to/conflicted-file.txt

С git checkout документы

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...

--ours
--theirs
When checking out paths from the index, check out stage #2 (ours) or #3 (theirs) for unmerged paths.

The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result.

Ответ mipadi не совсем сработал для меня, мне нужно было сделать это:

git checkout --ours path/to/file.bin

или, чтобы сохранить объединяемую версию:

git checkout --theirs path/to/file.bin

потом

git add path/to/file.bin

А потом я снова смог выполнить "git mergetool" и перейти к следующему конфликту.

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

1. Tortoise git позволяет настраивать инструменты сравнения / слияния для разных типов файлов в зависимости от их расширений. См. 2.35.4.3. Расширенные настройки Diff / Merge http://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html. Эта стратегия, конечно же, полагается на доступные подходящие инструменты сравнения / слияния.

2. Используя атрибуты git, вы можете указать инструмент / команду для преобразования вашего двоичного файла в текст, а затем позволить вашему инструменту сравнения / слияния по умолчанию сделать это. См. http://git-scm.com/book/it/v2/Customizing-Git-Git-Attributes. В статье даже приводится пример использования метаданных для сравнения изображений.

У меня есть обе стратегии для работы с двоичными файлами моделей программного обеспечения, но мы выбрали черепаховый git, поскольку настройка была простой.

Если двоичный файл - это нечто большее, чем dll или что-то, что может быть отредактировал напрямую, например изображение или смешанный файл (и вам не нужно удалять / выбирать один или другой файл), настоящее слияние будет примерно таким:

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

• npm install -g imagediff IIRC из https://github.com/uber/image-diff
• или python https://github.com/kaikuehne/mirror.git
• есть другие там

и сравните их.

Если нет инструмента сравнения для сравнения ваших файлов, то если у вас есть оригинальный генератор файла bin (то есть есть редактор для него ... как blender 3d, вы можете вручную проверить эти файлы, также просмотреть журналы, и спросите другого человека, что вам следует включить) и делаем вывод файлов с https://git-scm.com/book/es/v2/Git-Tools-Advanced-Merging#_manual_remerge

$ git show :1:hello.blend > hello.common.blend
$ git show :2:hello.blend > hello.ours.blend
$ git show :3:hello.blend > hello.theirs.blend

Я использую Git Workflow for Excel - приложение https://www.xltrail.com/blog/git-workflow-for-excel для решения большинства проблем слияния, связанных с моими двоичными файлами. Это приложение с открытым исходным кодом помогает мне эффективно решать проблемы, не тратя слишком много времени, и позволяет мне выбирать правильную версию файла без каких-либо затруднений.

Эта процедура предназначена для разрешения конфликтов двоичных файлов после того, как вы отправили запрос на перенос в Github:

1. Итак, на Github вы обнаружили, что ваш пул-реквест имеет конфликт с двоичным файлом.
2. Теперь вернитесь к той же ветке git на локальном компьютере.
3. Вы (а) заново создаете / пересобираете этот двоичный файл и (б) фиксируете полученный двоичный файл в той же ветке git.
4. Затем вы снова отправляете эту же ветку git в Github.

В Github по вашему запросу на вытягивание конфликт должен исчезнуть.

мой случай кажется ошибкой .... используя git 2.21.0

Я потянул ... он пожаловался на двоичные файлы:

warning: Cannot merge binary files: <path>
Auto-merging <path>
CONFLICT (content): Merge conflict in <path>
Automatic merge failed; fix conflicts and then commit the result.

И затем ни один из ответов здесь не привел к каким-либо выводам, которые имели бы какой-либо смысл.

Если я посмотрю, какой файл у меня сейчас ... это тот, который я редактировал. Если я это сделаю:

git checkout --theirs -- <path>
git checkout --ours -- <path>

Получаю вывод:

Updated 0 paths from the index

и у меня все еще есть моя версия файла. Если я rm, а затем оформлю заказ, вместо этого он скажет 1, но все равно предоставит мне мою версию файла.

git mergetool говорит

No files need merging

и статус git говорит

    All conflicts fixed but you are still merging.
    (use "git commit" to conclude merge)

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

чтобы разрешить это безумие:

Я просто сбежал

git commit

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

git checkout <commit where the remote version exists> <path>

что возвращает мне удаленную версию

затем снова отредактировал файл ... а затем зафиксировал и нажал, что опять же, вероятно, означает трату места на другую копию двоичного файла.