树冲突是git中因文件路径操作不一致（如删除、重命名）导致的元信息冲突，不显示

什么是树冲突（tree conflict）

当两个分支对同一文件做了不同路径操作——比如一个分支删了 src/utils/format.js，另一个分支把它重命名为 src/lib/formatter.js——Git 就无法判断该保留哪个路径，会报出树冲突，而不是内容冲突。这种冲突不会出现 标记，<code>git status 会显示类似 deleted by us、added by them 或 renamed in both 的状态，属于 Git 三路合并中“文件元信息不一致”的典型表现。

用 git status 和 git ls-files -u 定位树冲突文件

执行 git merge 报错后，先别急着删或改：

Github Stars Analyzer

抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...

下载

• git status 会列出处于 Unmerged paths 的文件，并附带具体动作描述，例如：deleted by us, added by them
• git ls-files -u 能看到 Git 实际暂存的三个版本（base / ours / theirs），每个条目带 mode、hash 和 stage 编号（1=base，2=ours，3=theirs），帮你确认是否真有重命名/删除分歧
• 如果 git status 显示 both modified 但打开文件又没冲突标记，大概率是路径操作不一致，不是内容改写

手动修复树冲突的常见组合操作

树冲突没有通用解法，必须结合业务意图判断：这个文件到底该存在吗？该放在哪？以下是高频场景对应的操作：

• 你删了文件，对方重命名了它 → 通常应保留重命名后的版本：git rm <old-path></old-path>，再 git add <new-path></new-path>
• 你重命名了文件，对方也重命名成不同名字 → 选一个合理路径，用 git mv 统一，再 git add 新路径
• 双方都删除了同一文件 → 直接 git rm <file></file>，然后 git add 不需要做
• 一方删、一方改内容（未动路径）→ 冲突本质是“删 vs 改”，需决定是否恢复文件；若要保留修改，先 git checkout --theirs <file></file> 拉回内容，再 git add <file></file>

rerere 对树冲突无效，别指望自动复用

git rerere 只记录内容冲突的解决方式，对文件路径变更类的树冲突完全无感。即使你之前解决过 utils/format.js → lib/formatter.js 的重命名冲突，下次遇到类似但路径不同的变动（比如改成 shared/formatter.ts），rerere 不会触发。这类冲突必须每次人工判断路径合理性，尤其要注意团队约定的目录规范（如 lib/ 专放工具函数、shared/ 仅用于跨模块复用），否则容易在后续合并中反复踩坑。