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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

git mergetool

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

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

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

Answer 4

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

git commit -a

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

git checkout otherbranch theconflictedfile
git commit -a

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

Answer 5

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

git checkout -наш путь/к/файлу.bin

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

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

тогда

git добавляет путь/к/файлу.bin

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

Answer 6

Из самого git checkout Документы

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

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

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

Answer 7

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

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

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

Answer 8

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

% git fetch

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

% git checkout FETCH_HEAD stuff/to/update

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

Answer 9

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

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

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

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

Answer 10

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

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

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

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

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

Answer 11

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

Answer 12

мой случай похож на ошибку....использование 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>

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

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