为何Git在双方均删除文件时提示"deleted merge conflict"？
2026-5-19
为什么两边都删除文件还会出现deleted merge conflict？
嘿，这个问题我碰到过好几次，看似有点反常识，但其实是Git合并逻辑里的小细节在搞鬼，我给你掰扯清楚：
核心原因：Git关注的不只是结果，还有操作上下文
虽然你和master分支都把文件删了，但Git判断冲突的时候，不只会看最终状态，还会追踪删除操作的上下文和历史，以下几种情况都会触发这个冲突：
- 删除的提交背景不同：比如你的分支是在修改了文件内容的某个提交后删除的，而master分支是在另一个版本的文件基础上删除的。Git会觉得“两边都是删，但删的不是同一个版本的文件”，需要你手动确认这个删除是没问题的。
- 删除的方式不一样：如果你是用
rm <文件名>之后只提交了删除，但master分支是用git rm <文件名>（同时移除文件和Git追踪），或者反过来用了git rm --cached只取消追踪，这种操作上的差异会让Git认为两边的删除状态不一致，触发冲突。 - 合并基础的历史分歧：如果你的分支和master分支最近的共同祖先里这个文件是存在的，两边各自独立删除，但Git在合并时，会默认检查这类“双方都修改/删除同一文件”的场景，哪怕结果一样，也可能要求你手动确认，避免遗漏关联的变更。
快速解决方法
既然确认两边都要删除这个文件，解决起来很简单：
- 先确认当前状态：用
git status看看冲突的文件标记，会显示deleted by us或者deleted by them - 直接执行
git add <冲突的文件名>，Git会把这个删除操作标记为已解决 - 或者执行
git rm <冲突的文件名>（虽然文件已经删了，但这会明确告诉Git你确认要删除） - 最后完成合并：
git commit就可以了
如果还是有奇怪的状态，也可以先git merge --abort取消合并，拉取最新的master分支后再重新合并，大概率能解决。
内容的提问来源于stack exchange，提问作者Jez
相关产品推荐
相关产品推荐
