Блог

Главная - Вопросы по программированию - Конфликт перебазирования Git, в котором нечего объединять?

Конфликт перебазирования Git, в котором нечего объединять?

#git #conflict #rebase

#git #конфликт #перебазирование

Вопрос:

Что это значит, когда перебазирование git обнаруживает конфликт, но в файле нет явной проблемы? В рассматриваемом файле нет маркеров конфликта и git mergetool написано «нечего объединять».

У меня есть следующие варианты: сбросить или добавить:

 # Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      filename.js

Как мне узнать, о чем идет речь и какой путь выбрать?

git ls-files -s filename.js дает 3 строки:

 100644 d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 1   filename.js
100644 9010798f1d19ac712196b1fc9b0870fd332b1275 2   filename.js
100644 b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 3   filename.js

Согласно руководству fine, эта команда сообщает нам биты режима, имя объекта и номер этапа. Биты режима те же. Итак, что такое 1, 2 и 3, и почему они «оба изменены», но не показывают маркеры конфликта?

Комментарии:

1. Это могут быть различия в пробелах.

2. Попробуйте git ls-files -s filename.js посмотреть, действительно ли версии отличаются.

3. @JoshLee Я обновил свой вопрос в ответ на ваш комментарий. На выходе отображаются 3 больших двоичных объекта, но я не уверен, куда идти дальше, как мне найти различия или определить, какой из них «добавить» или «сбросить»?

4. @birryree Не будут ли различия в пробелах отображаться с <<< маркерами конфликта?

5. Вы правы, игнорируйте меня.

Ответ №1:

Версии в индексе отмечены 1 , 2 , и 3 имеют следующее значение:

  1. Файл в том виде, в каком он был у общего предка двух коммитов, которые вы объединяете.
  2. Файл в том виде, в котором он был HEAD , то есть ваш текущий коммит, когда вы выполняли слияние.
  3. Файл в том виде, в котором он находится в фиксации, в которую вы пытаетесь объединить HEAD .

Мой источник этой информации — полезный раздел руководства по git, посвященный разрешению конфликтов.

both modified Вывод git status , конечно, указывает, что файл был изменен по-разному двумя коммит, которые вы объединяете, начиная с их общего предка.

Однако для меня довольно загадочно, почему вы не видите маркеров конфликта в файле — то, что большие двоичные объекты имеют разные имена объектов (хэши) в выходных git ls-files -s данных, указывает на то, что байт за байтом они, безусловно, имеют разное содержимое. Если вы довольны файлом в том виде, в каком он есть в вашей рабочей копии, вы можете просто сделать git add filename.js and then git rebase --continue . Однако в любом случае вы можете захотеть выяснить, в чем заключалась эта разница. Чтобы сделать это, я бы попробовал следующее:

 git diff :2:filename.js filename.js

… который покажет различия между версией в HEAD и вашей текущей рабочей копией. Аналогичным образом, вы можете попробовать:

 git diff :3:filename.js filename.js

… чтобы увидеть разницу между версией, которая была объединена, и вашей рабочей копией.

Ответ №2:

The 1 , 2 и 3 of git ls-files -s представляет «стадию» 3-стороннего слияния: 1 является общим предком, 2 текущим заголовком ветки и 3 другим заголовком ветки. В Linux вы можете попробовать следующие команды, чтобы увидеть, что отличается от файлов:

 $ git cat-file blob d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 | xxd -ps
$ git cat-file blob 9010798f1d19ac712196b1fc9b0870fd332b1275 | xxd -ps
$ git cat-file blob b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 | xxd -ps
Метки: