合并时git如何处理重命名的文件？

Question

有人能描述合并时git如何处理重命名的文件吗？

当合并重命名文件提交时，我面临一个问题。

前任：

in master

提交1:添加b.txt

我的主文件夹视图：

b.txt

特征中的

提交1:添加b.txt this is not the same commit, just same change

提交2:将b.txt移动到my文件夹/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).But --它看起来不像是合并一个分支的正确方法。

更新：

通过way2，如果我使用重基而不是合并，它将给我“正确”的结果。

Answer 1

这些评论确实指出了在git中处理重命名的一些细微差别，但它们并没有真正解决您所看到的原因。

当git进行合并时，它不会单独查看分支的提交。相反，它关注三件事:合并基(大致上是最近的公共祖先)；“我们的”提交(您要合并的分支的尖端)；以及“它们的”提交(您要合并的分支的尖端)。

它将"base“与"our”进行比较，以确定“我们的更改”，并看到您创建了b.txt。它将“基本”与“他们的”进行比较，以确定“他们的变化”，而这正是事情不像你所希望的那样。因为它不查看中间状态，所以它不知道您创建了b.txt，然后将它移动到myfolder/b.txt；它只知道在分支过程中创建了myfolder/b.txt。

所以变化的联合是“创建b.txt和创建myfolder/b.txt"，并且没有冲突，所以两者都是。

有趣的是，虽然merge和rebase通常产生相同的结果，并且只在它们产生的历史中被认为是不同的，但是在这种情况下，重基是非常罕见的，因为它确实会单独查看每个提交的更改，从而产生更直观的结果。