Разрешение конфликта Git с двоичными файлами
Я использовал Git в Windows (msysgit) для отслеживания изменений для некоторых проектных работ, которые я делал.
Сегодня я работал на другом ПК (с удаленным репо brian
), и теперь я пытаюсь объединить изменения, сделанные сегодня, в мою обычную локальную версию на моем ноутбуке.
На моем ноутбуке я использовал git pull brian master
, чтобы внести изменения в мою локальную версию. Все было отлично от основного документа InDesign - это показывает как конфликт.
Версия на ПК (brian
) является последней, которую я хочу сохранить, но я не знаю, какие команды говорят об этом репо.
Я попытался напрямую скопировать файл на свой ноутбук, но это, похоже, нарушит весь процесс слияния.
Может ли кто-нибудь указать мне в правильном направлении?
Ответы
Ответ 1
git checkout
принимает параметр --ours
или --theirs
для таких случаев. Поэтому, если у вас возник конфликт слиянием, и вы знаете, что просто хотите, чтобы файл из ветки, с которой вы сливаетесь, вы можете сделать:
$ git checkout --theirs -- path/to/conflicted-file.txt
чтобы использовать эту версию файла. Аналогично, если вы знаете, что хотите, чтобы ваша версия (а не та, которая была объединена), вы можете использовать
$ git checkout --ours -- path/to/conflicted-file.txt
Ответ 2
Вы должны разрешить конфликт вручную (копируя файл), а затем зафиксировать файл (независимо от того, скопировали ли вы его или использовали локальную версию), как этот
git commit -a -m "Fix merge conflict in test.foo"
Git обычно автоматически записывается после слияния, но когда он обнаруживает конфликты, он не может решить сам по себе, он применяет все исправления, которые он вычисляет, и оставляет все остальное для вас, чтобы разрешить и зафиксировать вручную. Git Страница слияния человека, Git -SVN Crash Course или эта запись в блоге может пролить свет на то, как она должна работать.
Изменить: См. сообщение ниже, вам не нужно копировать файлы самостоятельно, но можете использовать
git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt
чтобы выбрать версию нужного файла. Копирование/редактирование файла будет необходимо только в том случае, если вы хотите использовать сочетание обеих версий.
Пожалуйста, отметьте ответ mipadis как правильный.
Ответ 3
Вы также можете преодолеть эту проблему с
git mergetool
что заставляет git
создавать локальные копии конфликтующих двоичных файлов и создавать на них ваш редактор по умолчанию:
-
{conflicted}.HEAD
-
{conflicted}
-
{conflicted}.REMOTE
Очевидно, что вы не можете с пользой редактировать двоичные файлы в текстовом редакторе. Вместо этого вы копируете новый {conflicted}.REMOTE
файл поверх {conflicted}
не закрывая редактор. Затем, когда вы закроете редактор, git
увидит, что недекорированная рабочая копия была изменена, и ваш конфликт слияния разрешен обычным способом.
Ответ 4
Чтобы решить, сохранив версию в текущей ветке (игнорируйте версию из ветки, в которую вы объединяетесь), просто добавьте и зафиксируйте файл:
git commit -a
Чтобы разрешить, перезаписав версию в своем текущем ветки версией из ветки, в которую вы входите, вам нужно сначала извлечь эту версию в ваш рабочий каталог, а затем добавить/зафиксировать ее:
git checkout otherbranch theconflictedfile
git commit -a
Объяснено более подробно
Ответ 5
Ответ mipadi для меня не совсем сработал, мне нужно было сделать это:
git checkout --ours path/to/file.bin
или, чтобы сохранить версию в:
git checkout - theways path/to/file.bin
затем
git добавить путь/в/file.bin
И затем я смог снова выполнить "git mergetool" и перейти к следующему конфликту.
Ответ 6
Из git checkout
docs
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
--ours
--theirs
При проверке путей из индекса проверьте этап # 2 (ours
) или # 3 (theirs
) для несвязанных путей.
Индекс может содержать несвязанные записи из-за предыдущего неудачного слияния. По умолчанию, если вы попытаетесь проверить такую запись из индекса, операция проверки завершится неудачно, и ничего не будет проверено. Использование -f
будет игнорировать эти несвязанные записи. Содержимое с определенной стороны слияния можно проверить из индекса с помощью --ours
или --theirs
. С помощью -m
изменения, внесенные в рабочий файл дерева, могут быть отброшены, чтобы повторно создать исходный конфликтный результат слияния.
Ответ 7
Эта процедура предназначена для разрешения конфликтов двоичных файлов после того, как вы отправили запрос на извлечение в Github:
- Итак, на Github вы обнаружили, что ваш запрос на удаление конфликтует с двоичным файлом.
- Теперь вернитесь в ту же ветку git на вашем локальном компьютере.
- Вы (а) заново создаете/перестраиваете этот двоичный файл снова и (б) фиксируете полученный двоичный файл в той же самой ветке git.
- Затем вы снова толкаете эту ветку Git в Github.
На Github, по вашему запросу, конфликт должен исчезнуть.
Ответ 8
Я столкнулся с подобной проблемой (желая вытащить фиксацию, которая включала некоторые двоичные файлы, вызвавшие конфликты при объединении), но натолкнулась на другое решение, которое можно сделать полностью с помощью git (т.е. не нужно вручную копировать файлы над). Я подумал, что я включу его здесь, чтобы по крайней мере я помню его в следующий раз, когда мне это нужно.:) Шаги выглядят так:
% git fetch
Выбирает последние фиксации из удаленного репозитория (возможно, вам нужно указать имя удаленной ветки, в зависимости от вашей установки), но не пытается их объединить. Он записывает фиксацию в FETCH_HEAD
% git checkout FETCH_HEAD stuff/to/update
Это берет копию двоичных файлов, которые я хочу, и перезаписывает то, что в рабочем дереве с версией, полученной из удаленной ветки. git не пытается слить, поэтому вы просто получаете точную копию двоичного файла из удаленной ветки. После этого вы можете добавить/скопировать новую копию, как обычно.
Ответ 9
Я столкнулся с двумя стратегиями для управления diff/merge из двоичных файлов с Git в Windows.
-
Tortoise Git позволяет вам настраивать инструменты diff/merge для разных типов файлов на основе их расширений файлов. См. 2.35.4.3. Расширенные настройки Diff/Merge http://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html. Эта стратегия, конечно, полагается на подходящие инструменты для разграничения/слияния.
-
Используя атрибуты Git, вы можете указать инструмент/команду, чтобы преобразовать ваш двоичный файл в текст, а затем позволить вашему инструменту по умолчанию/слиянию по умолчанию сделать это. См. http://git-scm.com/book/it/v2/Customizing-Git-Git-Attributes. В статье даже приведен пример использования метаданных для сравнения изображений.
У меня есть обе стратегии работы с бинарными файлами программных моделей, но мы пошли с черепахой Git, так как конфигурация была легкой.
Ответ 10
Если двоичный файл содержит нечто большее, чем 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
Ответ 11
Я использую Git Workflow для Excel - приложение https://www.xltrail.com/blog/git-workflow-for-excel для решения большинства проблем слияния, связанных с моими двоичными файлами. Это приложение с открытым исходным кодом помогает мне продуктивно решать проблемы, не затрачивая слишком много времени, и позволяет мне без проблем выбрать нужную версию файла.
Ответ 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
и у меня все еще есть моя версия файла. Если я произвожу, а затем оформлю заказ, вместо этого будет указано "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>
который возвращает мне удаленную версию
затем снова отредактировал файл... и затем зафиксировал и нажал, что, вероятно, снова означает, что тратится место на другую копию двоичного файла.