Разрешение конфликта Git с бинарными файлами - PullRequest
Новая
       32

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

421 голосов
/ 10 ноября 2008

Я использую Git на Windows (msysgit), чтобы отслеживать изменения для некоторых дизайнерских работ, которые я делал.

Сегодня я работал на другом ПК (с удаленным репо brian) и сейчас пытаюсь объединить сделанные сегодня правки в мою обычную локальную версию на моем ноутбуке.

На моем ноутбуке я использовал git pull brian master, чтобы перенести изменения в мою локальную версию. Все было хорошо, кроме основного документа InDesign - это выглядит как конфликт.

Версия на ПК (brian) - последняя, ​​которую я хочу сохранить, но я не знаю, какие команды говорят репо использовать эту.

Я пытался напрямую скопировать файл на свой ноутбук, но это, похоже, нарушает весь процесс слияния.

Кто-нибудь может указать мне правильное направление?

Ответы [ 12 ]

780 голосов
/ 29 января 2010

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

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

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

$ git checkout --ours -- path/to/conflicted-file.txt
142 голосов
/ 10 ноября 2008

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

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

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

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

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

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

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

109 голосов
/ 24 августа 2009

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

git mergetool

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

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

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

16 голосов
/ 29 января 2010

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

git commit -a

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

git checkout otherbranch theconflictedfile
git commit -a

Более подробно объяснено

9 голосов
/ 24 ноября 2014

Ответ Мипади у меня не совсем сработал, мне нужно было сделать следующее:

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

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

git checkout - их путь / к / file.bin

тогда

git add path / to / file.bin

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

5 голосов
/ 30 мая 2013

Из git checkout документов

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

--ours
--theirs
При проверке путей из индекса, проверьте этап № 2 (ours) или № 3 (theirs) для неотключенных путей.

Индекс может содержать необъединенные записи из-за предыдущего неудачного слияния. По умолчанию, если вы попытаетесь извлечь такую ​​запись из индекса, операция извлечения завершится неудачей и ничего не будет извлечено. Использование -f будет игнорировать эти необработанные записи. Содержимое определенной стороны слияния можно извлечь из индекса, используя --ours или --theirs. С -m изменения, внесенные в файл рабочего дерева, могут быть отклонены, чтобы заново создать исходный конфликтующий результат слияния.

4 голосов
/ 27 марта 2019

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

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

На Github, по вашему запросу, конфликт должен исчезнуть.

3 голосов
/ 22 июля 2009

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

% git fetch

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

% git checkout FETCH_HEAD stuff/to/update

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

1 голос
/ 14 августа 2015

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

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

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

Если нет инструмента сравнения для сравнения ваших файлов, то если у вас есть оригинальный генератор файла 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

1 голос
/ 27 ноября 2014

Я сталкивался с двумя стратегиями управления diff / слиянием бинарных файлов с помощью 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 / Настройка-Git-Git-Атрибуты . В статье даже приведен пример использования метаданных для сравнения изображений.

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

Страница:
...