Git合并feature到develop时文件被重命名为原名的问题排查

核心原因 #

• Git的重命名推断逻辑：Git没有原生的“重命名”操作，它靠内容相似度判断文件是否被重命名。默认阈值是50%的内容匹配度——你在feature分支修改了30-40%的内容，刚好卡在阈值边缘，合并时Git对比develop的原文件和feature的新文件，判定两者是同一文件的修改，而非“删除原文件+创建新文件”，于是自动把feature的文件改回develop的原路径和文件名。
• 三方合并的状态冲突：develop分支在你开发feature期间持续更新，原文件也有内容变更。合并时Git会对比三个版本（base基础版、develop当前版、feature修改版）：如果base里原文件存在，develop里原文件仍在且有改动，feature里原文件被删、新文件内容和原文件相似度达标，Git就会把新文件的修改合并到原路径下，而非保留feature的重命名。
• GUI工具的自动处理：你用的Git扩展GUI默认开启了重命名检测，且未提供手动确认环节，直接按照Git的推断自动完成合并，导致结果不符合预期。

解决建议 #

• 先反向合并解决冲突：先把develop分支合并到feature分支，在feature里手动确认重命名状态（保留新路径/文件名），解决所有冲突后，再将feature合并到develop。
• 调整重命名检测阈值：合并时用git merge -X rename-threshold=60%命令，把相似度阈值调高（比如60%），这样30-40%的内容修改就不会被Git判定为重命名。
• 手动标记重命名状态：如果合并时Git误判，手动执行git rm 原文件路径和git add 新文件路径，明确告诉Git这是重命名操作，再完成合并。

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