重命名冲突典型报错含“CONFLICT (rename/add)”及“added in...inside a directory that was renamed in...”；根本原因是Git依赖内容相似度推测重命名，分支间重命名或增删不一致导致误判。
重命名冲突的典型报错长什么样
执行 git merge 或 git pull 时，如果看到类似这样的输出，基本可以确认是重命名冲突：
CONFLICT (rename/add): client/Assets/Plugins/JSZX_tools/VXExplorer/Editor/PreviewWindow/ParticleSystemPreview/Editor/PreviewReimportListener.cs added in remotes/origin/publish inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to client/Assets/JoyBoxSdk/Bean/PreviewReimportListener.cs.
这类提示里反复出现 rename、added in ... inside a directory that was renamed in ...，不是普通文本冲突，而是 Git 在路径层面“认不出文件身份”了。
根本原因在于：Git 本身不直接记录“重命名”操作，而是靠内容相似度 + 路径变化来推测。当两个分支各自对同一文件做了重命名（或一个重命名、一个新增同名文件），Git 的 find_renames 算法就可能误判——比如把 A 分支里删掉的旧路径 + B 分支里新增的同名文件，强行匹配成“重命名”，结果路径对不上，就卡住。
git merge --no-renames 是诊断第一步
别急着手动改路径或删文件。先用这个参数让 Git 暂时关闭重命名检测，看真实差异是什么：
- 运行
git merge --no-renames feature-branch，如果冲突消失，说明问题确实出在重命名逻辑上 - 再运行
git status，你会看到更清晰的状态：可能是deleted by us+added by them，或者两个renamed条目并列 - 此时用
git diff --name-only HEAD...feature-branch查看实际增删路径，比对着报错里的“suggested move”判断是否合理
这步的关键作用是绕过 Git 的自动推测，把决策权拿回来。很多团队跳过这步，直接硬解，结果把本该保留的文件删了，或把新功能路径写错了。
手动解决时必须确认三件事
重命名冲突不能只看文件名，得结合语义和项目结构做判断。打开冲突文件（如果有）或检查报错路径后，务必核实：
- 那个被“建议移动”的目标路径（如
client/Assets/JoyBoxSdk/Bean/PreviewReimportListener.cs）在当前工作区是否已存在？如果已存在且内容不同，说明不是简单重命名，而是两个分支各自新建了同名文件 - 原始路径（如
client/Assets/Plugins/JSZX_tools/...）下的文件是否真的被删除？用git ls-files | grep PreviewReimportListener确认它是否还在索引中 - 该文件的用途是否已被迁移？比如旧路径属于废弃模块，新路径才是当前主干使用的，那应该以新路径为准，并确保所有引用（import、require、Unity meta 文件等）同步更新
漏掉任意一点，都可能导致编译失败或运行时找不到类。尤其 Unity 项目里，.cs 和 .cs.meta 必须成对处理，单独改一个会触发 AssetDatabase 重建异常。
长期避免重命名冲突的配置项
Git 默认的重命名检测阈值（50% 内容相似）对代码文件偏宽松，容易误判。可在项目根目录加 .gitattributes 显式控制：
*.cs merge=union *.meta merge=union
再配全局设置提升精度：
-
git config --global diff.renameLimit 999999（避免大仓库下 rename 检测被截断） git config --global merge.renamelimit 999999- 关键操作前运行
git status -sb，留意是否有renamed:提示——这是提前发现潜在冲突的信号
最易被忽略的是：重命名操作本身最好拆成两步提交——先提交重命名（git mv），再提交内容修改。这样在合并时，Git 能明确识别出“路径变更”和“内容变更”是两个独立动作，而不是混在一起猜。
