为什么Git不尝试合并重命名文件的更改？

Question

假设我有一个文件，它：

1. 在主分支中被修改过
2. 在一个特性分支中被修改过
3. 在一个特性分支中被重命名了

当我尝试从主分支向特性分支合并时，合并失败并出现以下信息：

冲突（修改/删除）：X已在HEAD中被删除，并在origin/master中被修改。版本origin/master的X留在树中。

我知道这里存在冲突，但为什么它不试图合并更改并在文件中放置冲突标记呢？以前的答案似乎暗示着它应该这样做。我得到的只是两个不同版本的文件，我必须手动找出差异并逐行将更改从主版本移到我的版本。

复现步骤：

git init
touch a
git add a
git commit -m 'initial import'

git checkout -b feature1
echo feature1 > a
git add a
git commit -m feature1
git mv a b
git commit -m feature1

git checkout master
echo bugfix > a
git add a
git commit -m bugfix

git checkout feature1 
git merge master 

- Alex B

---

可能 重复。 - kostix

Answer 1

由于在git中实际上不存在一级重命名操作的概念，它只是使用文件差异的阈值来“检测”重命名。你的文件可能太不相似了。

尝试使用以下合并命令： git merge master -s recursive -X rename-threshold=5%

- akent

---

当您最初提交重命名时，似乎已经使用了一个阈值，因为重命名的文件可能包含一些小差异。不知道为什么它不会使用相同的阈值？我期望它在合并或变基时能够保持对初始提交中重命名的识别。 - Sean Adkinson

@SeanAdkinson 因为默认的合并策略仅合并最终结果，而不是每个提交。因此，如果在重命名后的另一个提交中更改了文件，则即使之前满足阈值，现在也可能不再满足。 - gcscaglia

请注意，在 rename-threshold 中的 % 是至关重要的。 - Mike Caron