有人能描述git在合并时如何处理重命名的文件吗？
合并重命名的文件提交时遇到问题。
例如：
在大师中
提交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而不是merge，它将给我“正确”的结果。
答案 0 :(得分：1)
评论的确指出了在git中处理重命名的一些细微差别，但它们并没有真正解决您所看到的原因。
当git进行合并时，不单独查看分支的提交。相反，它着眼于三件事：合并基础（大概是最近的共同祖先）； “我们的”提交（您要合并到的分支的尖端）；和“他们的”提交（您要合并的分支的尖端）。
它将“基本”与“我们的”进行比较以确定“我们的更改”，并且看到您创建了b.txt。它将“基础”与“他们的”进行比较，以确定“他们的变化”，这就是您所不希望的地方。因为它不查看中间状态，所以它不知道您创建了b.txt，然后将其移至myfolder/b.txt；它只知道在分支过程中创建了myfolder/b.txt。
因此，更改的并集为“创建b.txt和创建myfolder/b.txt”，并且其中没有冲突，因此两者都可以。
有趣的是，虽然merge和rebase 通常产生相同的结果，并且被认为只是它们产生的历史不同，但这是非常变基的极少数情况是因为它可以单独查看每个提交的更改，因此可以产生更直观的结果。