如何让Git工具更好地追踪文件重命名？

核心原理先明确 #

Git并不直接在历史里记录文件重命名操作，它靠内容相似度匹配的启发式算法来识别：对比不同提交间的文件内容，当相似度超过默认阈值（50%）时，就判定为文件重命名。但工具的实现差异会导致追踪体验参差不齐，尤其是带修改的重命名场景。

三种操作方式的效果拆解 #

1. 同时提交重命名和修改 #

操作流程：

git mv foo.txt bar.txt
# 修改bar.txt内容（仅1%变更）
git commit -m "rename foo.txt to bar.txt and modify"

这种情况下，Git需要在单个提交里对比foo.txt（被删除）和bar.txt（新增且修改）的内容，因为相似度高达99%，Git CLI能识别，但部分工具（比如Eclipse）的启发式逻辑对同提交内的“重命名+修改”组合处理不佳，容易出现追踪断裂。

2. 分两次提交：先纯重命名，后修改 #

操作流程：

# 第一步：纯重命名提交
git mv foo.txt bar.txt
git commit -m "rename foo.txt to bar.txt"
# 第二步：修改内容提交
# 修改bar.txt内容
git commit -m "modify bar.txt content"

这是技术上最可靠的操作方式：

• 第一次提交是“纯重命名”，foo.txt和bar.txt内容完全一致，Git和绝大多数工具不需要依赖相似度阈值，能100%确定这是重命名操作，直接建立历史关联。
• 第二次提交仅处理内容变更，工具可以顺着已建立的重命名关联，无缝追踪bar.txt到foo.txt的完整历史。
• 对所有支持Git重命名识别的工具来说，这种方式的追踪成功率最高。

3. 分支分两次提交后合并（--no-ff） #

操作流程：

git checkout -b foobar
git mv foo.txt bar.txt
git commit -m "rename foo.txt to bar.txt"
# 修改bar.txt内容
git commit -m "modify bar.txt content"
git checkout main
git merge foobar --no-ff

这种方式的优势会被合并提交部分抵消：

• 在foobar分支里，确实存在纯重命名的提交，但合并到main后，合并提交的最终状态会显示“删除foo.txt、新增bar.txt且带修改”。
• 如果工具能遍历分支历史（比如Git CLI查看分支提交），依然能识别到纯重命名的线索，但对于只看main分支线性历史的工具来说，合并提交的状态和第一种“同时提交重命名+修改”的场景类似，追踪可靠性不如直接在主线分两次提交。

各工具的实际支持表现 #

Git CLI #

• 方式2：用git log --follow bar.txt能完美追踪到foo.txt的历史，纯重命名提交会给出明确的关联线索；用git diff --name-status -M查看第一次提交，会显示R100（完全匹配的重命名）。
• 方式1：因为修改量小，用git log --follow bar.txt也能识别，git diff会显示R99（相似度99%）。
• 方式3：需要指定查看分支历史（如git log --follow bar.txt foobar），或者在合并后用git log --follow --full-history bar.txt才能完整追踪，默认只看main分支的话体验和方式1一致。

VS Code #

• 方式2：支持极佳，查看bar.txt的历史时会自动关联foo.txt的提交记录，无需额外操作。
• 方式1：因为修改量小，多数情况下能自动识别重命名，历史追踪顺畅。
• 方式3：在查看合并提交的详细内容时，需要展开分支子提交才能看到纯重命名的记录，但手动关联后也能完整追踪，整体体验优于Eclipse。

Eclipse #

• 方式2：是唯一能稳定追踪的方式，纯重命名提交会让Eclipse Git插件明确建立文件历史关联，后续修改的历史也能无缝衔接。
• 方式1：经常出现无法识别重命名的情况，历史会断裂成foo.txt的旧记录和bar.txt的新记录。
• 方式3：合并提交的状态会让Eclipse难以识别重命名线索，追踪体验和方式1一样糟糕，必须手动切换到foobar分支才能看到完整关联。

内容的提问来源于stack exchange，提问作者Garret Wilson