Я использую Git на Windows (msysgit), чтобы отслеживать изменения для некоторых дизайнерских работ, которые я делал.
Сегодня я работал на другом ПК (с удаленным репо brian
) и сейчас пытаюсь объединить сделанные сегодня правки с моей обычной локальной версией на моем ноутбуке.
На моем ноутбуке я использовал git pull brian master
изменения в моей локальной версии. Все было хорошо, кроме основного документа InDesign - это выглядит как конфликт.
Версия на ПК ( brian
) - последняя, которую я хочу сохранить, но я не знаю, какие команды говорят репо использовать эту.
Я попытался напрямую скопировать файл на свой ноутбук, но это, кажется, нарушает весь процесс слияния.
Может кто-то указать мне верное направление?
источник
git checkout --ours
? Страница руководства предлагает (ИМХО), что checkout --ours / - их удалит изменение из списка «оба измененных, нужно объединить» и добавит его в индекс, и я думаю, что это не правильно. Я считаю, что вам нужно будет бежатьgit add
после проверки.git merge branch_name
).--their
и--ours
меняются местами, т. Е. --Their == текущая извлеченная ветвь, а --ours - это ветвь, обычно удаленная ветвь, или спецификация пути, которую вы пытаетесь объединить с текущей филиал. В[space]--[space]
опции устраняет неоднозначность на пути спецификацию между именем ветви и путем спецификацией , что и случаются, существует с тем же именем (например , имя существующей ветви «а» и каталог существует под название «ABC»).Вы должны разрешить конфликт вручную (перезаписать файл), а затем зафиксировать файл (независимо от того, скопировали ли вы его или использовали локальную версию) следующим образом
Обычно Git автоматически выполняет коммитирование после слияния, но когда он обнаруживает конфликты, которые он не может решить самостоятельно, он применяет все обнаруженные патчи и оставляет остальное для разрешения и фиксации вручную. Страница Git Merge Man Page , Git-SVN Crash Course или эта запись в блоге могут пролить свет на то, как она должна работать.
Изменить: см. Пост ниже, вы на самом деле не должны копировать файлы самостоятельно, но можете использовать
выбрать версию файла, который вы хотите. Копирование / редактирование файла будет необходимо, только если вы хотите смешать обе версии.
Пожалуйста, отметьте ответ mipadis как правильный.
источник
Вы также можете преодолеть эту проблему с
что заставляет
git
создавать локальные копии конфликтующего двоичного файла и порождать им редактор по умолчанию:{conflicted}.HEAD
{conflicted}
{conflicted}.REMOTE
Очевидно, что вы не можете с пользой редактировать двоичные файлы в текстовом редакторе. Вместо этого вы копируете новый
{conflicted}.REMOTE
файл,{conflicted}
не закрывая редактор. Затем, когда вы закроете редактор,git
вы увидите, что неокрашенная рабочая копия была изменена, и ваш конфликт слияния разрешен обычным способом.источник
Hit return to start merge resolution tool
"), и git оставит дополнительные файлы на месте. Затем вы можете изменить их или объединить во внешнем инструменте (полезно для двоичных форматов документов, таких как LibreOffice / OpenOffice / MSWord) и сохранить результат обратно в исходное имя файла. Чтобы сообщить git, что конфликт разрешен,git add
укажите исходное имя файла, и вы можете закончить коммит слияния.Чтобы решить, сохранив версию в текущей ветке (игнорируйте версию из ветви, в которую вы объединяете), просто добавьте и зафиксируйте файл:
Чтобы решить эту проблему, перезаписав версию в текущей ветке версией из ветви, в которую вы объединяете, вам нужно сначала извлечь эту версию в рабочий каталог, а затем добавить / зафиксировать ее:
Объяснено более подробно
источник
Ответ Мипади мне не помог, мне нужно было сделать следующее:
или, чтобы сохранить версию в:
тогда
И тогда я смог снова выполнить «git mergetool» и перейти к следующему конфликту.
источник
Из
git checkout
документовисточник
Я столкнулся с подобной проблемой (желая получить коммит, включающий некоторые двоичные файлы, которые вызывали конфликты при объединении), но натолкнулся на другое решение, которое может быть полностью выполнено с использованием git (то есть не нужно вручную копировать файлы). Я подумал, что включу это сюда, чтобы, по крайней мере, я мог вспомнить это в следующий раз, когда мне это понадобится. :) Шаги выглядят так:
Он выбирает последние коммиты из удаленного репозитория (вам может потребоваться указать имя удаленной ветви, в зависимости от вашей настройки), но не пытается объединить их. Записывает коммит в FETCH_HEAD
Это берет копию двоичных файлов, которые я хочу, и перезаписывает то, что находится в рабочем дереве с версией, извлеченной из удаленной ветви. git не пытается выполнить слияние, поэтому вы просто получаете точную копию двоичного файла из удаленной ветви. Как только это будет сделано, вы можете добавить / зафиксировать новую копию, как обычно.
источник
Эта процедура предназначена для разрешения конфликтов двоичных файлов после того, как вы отправили запрос на извлечение в Github:
На Github, по вашему запросу, конфликт должен исчезнуть.
источник
Если двоичный файл представляет собой нечто большее, чем 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
источник
Я столкнулся с двумя стратегиями управления diff / слиянием бинарных файлов с помощью Git на windows.
Git Tortoise позволяет вам настраивать инструменты сравнения / слияния для разных типов файлов в зависимости от их расширений. См. 2.35.4.3. Дополнительные настройки Diff / Merge http://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html . Эта стратегия, конечно, зависит от наличия подходящих инструментов сравнения / слияния.
Используя атрибуты git, вы можете указать инструмент / команду для преобразования вашего двоичного файла в текст, а затем позволить своему стандартному инструменту diff / merge сделать свое дело. См. Http://git-scm.com/book/it/v2/Customizing-Git-Git-Attributes . В статье даже приведен пример использования метаданных для сравнения изображений.
Я получил обе стратегии для работы с бинарными файлами программных моделей, но мы пошли с черепаховым мерзавцем, так как конфигурация была простой.
источник
Я использую Git Workflow для Excel - приложение https://www.xltrail.com/blog/git-workflow-for-excel, чтобы решить большинство проблем слияния, связанных с моими двоичными файлами. Это приложение с открытым исходным кодом помогает мне продуктивно решать проблемы, не затрачивая слишком много времени, и позволяет мне без проблем выбрать нужную версию файла.
источник
мой случай выглядит как ошибка .... с помощью GIT 2.21.0
Я сделал тянуть ... он жаловался на двоичные файлы:
И тогда ни в одном из ответов здесь не было никакого результата, который имел бы смысл.
Если я посмотрю, какой файл у меня сейчас ... это тот, который я отредактировал. Если я сделаю либо:
Я получаю вывод:
и у меня все еще есть моя версия файла. Если я произвожу, а затем оформлю заказ, вместо него будет 1, но он все равно даст мне мою версию файла.
Git Mergetool говорит
и Git статус говорит
Один из вариантов - отменить коммит ... но мне не повезло, у меня было много коммитов, и этот плохой был первым. Я не хочу тратить время на это.
так что решить это безумие
Я только что побежал
который теряет удаленную версию и, вероятно, тратит некоторое пространство на хранение дополнительного двоичного файла ... тогда
который возвращает мне удаленную версию
затем снова отредактировал файл ... и затем подтвердил и нажал, что, вероятно, снова означает, что тратится место на другую копию двоичного файла.
источник
git checkout --ours <path>
я получилUpdated 0 paths from the index
. Я исправил это с помощьюgit add <path>
команды, которая делает то же самое.