Как git обрабатывает переименованный файл при слиянии?

Question

Кто-нибудь может описать, как git обрабатывает переименованный файл при слиянии?

Я сталкиваюсь с проблемой при слиянии переименованного файла.

Например:
в master
коммит 1: добавить b.txt

просмотр моей главной папки:

b.txt

в функции
коммит 1: добавить b.txt this is not the same commit, just same change
коммит 2: переместить b.txt в myfolder / b.txt it show renamed file in git ui

мой вид папки функций:

myfolder/b.txt

Когда я в мастере, я делаю

git merge feature

Я думал, что смогу получить это:
мой вид главной папки после слияния:

myfolder/b.txt

Но git не удаляет b.txt, вместо этого мой конечный результат мастера:

b.txt  
myfolder/b.txt  

Не могу понять, почему мой коммит 2 в функциональной ветке уже не удалил b.txt?Почему это все еще в моем объединенном мастере.

Кстати, если я просто выберу вишню в коммите 2 в ветви функций, он будет работать хорошо (удалите b.txt). Но это не выглядит как правильныйспособ слияния ветки.

обновление:
Кстати, если я использую rebase вместо слияния, это даст мне "правильный" результат.

Answer 1

Комментарии указывают на некоторые нюансы работы с переименованиями в git, но на самом деле они не учитывают причину того, что вы видите.

Когда git выполняет слияние, оно не смотрит на коммиты веток индивидуально.Вместо этого он рассматривает три вещи: базу слияния (последний общий пример, примерно);«наш» коммит (вершина ветви, в которую вы сливаетесь);и "их" фиксация (конец ветви, в которую вы сливаетесь).

Он сравнивает "базу" с "нашей", чтобы определить "наши изменения", и видит, что вы создали b.txt.Он сравнивает «базу» с «их», чтобы определить «их изменения», и здесь все не так, как вы надеялись.Поскольку он не смотрит на промежуточные состояния, он не знает, что вы создали b.txt, а затем переместили его в myfolder/b.txt;он только знает, что в ходе ветки было создано myfolder/b.txt.

Таким образом, объединение изменений - это «создать b.txt и создать myfolder/b.txt», и в этом нет конфликта,так что он просто делает и то, и другое.

Интересно то, что merge и rebase обычно дают один и тот же результат и считаются отличающимися только в истории, которую они производят,это очень редкий случай, когда rebase, поскольку просматривает изменения каждого коммита отдельно, может дать более интуитивный результат.