conflict (modify/delete)表示一分支修改文件而另一分支删除它，需先判断文件是否应保留：若该留则用git checkout --ours恢复，该删则git rm并git add；核心是明确业务需求而非仅操作文件。

git merge 时提示 CONFLICT (modify/delete) 怎么办

这是 Git 明确告诉你：一个分支修改了某个文件，另一个分支却把它删掉了。它没法自动决定“该保留修改还是尊重删除”。这种冲突比 content 冲突更隐蔽，容易被忽略，但后果更严重——比如误删配置或关键类。

常见现象：CONFLICT (modify/delete): config/database.yml in branch 'main' and 'feature/user-auth'，git status 显示该文件状态为 deleted by them 或 modified by them（取决于你当前在哪个分支）。

• 先别急着编辑文件——它可能已经不在工作区了（被另一方删了），强行 touch 或恢复会扰乱 Git 判断
• 用 git status -s 看清标记：DD 表示双方都删了；MD 表示你删了、对方改了；DM 表示你改了、对方删了
• 核心判断点：这个文件是否还应该存在？是业务逻辑需要保留（比如 database.yml），还是确实该淘汰（比如已废弃的旧工具脚本）？

DM 类型冲突：你改了，对方删了文件

典型场景：你在 main 上修复了 src/Utils.java 的空指针问题，同事在 feature/cleanup 中认为这个类已无用，直接 git rm src/Utils.java 并提交。

One-click installation of GitHub projects

GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。

下载

• 如果确认该文件仍需保留（你的修改有效），执行 git checkout --ours src/Utils.java 恢复你改过的版本
• 如果确认该文件确实该删（比如同事已用新模块替代），就不用恢复，直接 git rm src/Utils.java
• 无论哪种选择，之后都必须 git add src/Utils.java（即使你删了它，也要显式 git add 来标记“已解决”）

MD 类型冲突：你删了，对方改了文件

比如你在 feature/api-v2 中删掉旧版接口 src/v1/ApiController.java，而 main 上有人刚给它加了日志埋点。

• 如果删除合理（v1 接口已下线），执行 git checkout --theirs src/v1/ApiController.java 会把对方改过的文件拉回来——这不对，你得先删干净：git rm src/v1/ApiController.java
• 如果删除不成立（比如只是临时注释，不该物理删除），就用 git checkout --theirs src/v1/ApiController.java 拿回对方的修改，再手动删掉你不想要的部分
• 注意：--theirs 在 merge 场景中指的是“被合并进来的分支”，不是远程分支——别被名字绕晕

如何避免 modify/delete 冲突反复发生

这类冲突往往暴露协作盲区：没人同步“这个文件要不要删”。它不像代码行冲突那么直观，容易在 code review 里漏掉。

• 在 PR 描述里强制写明“本次删除了 X 文件，原因：Y”，让 reviewer 主动确认是否影响其他分支逻辑
• 对配置类、启动类、路由定义等高共享度文件，建立“删除前需 @ 相关 owner”机制
• git rm 后不要立刻 push，先 git diff --cached 看看删的是不是真没人动——尤其注意 .yml/.json/.xml 这类文本配置，常被多人同时修改

真正麻烦的不是解决过程，而是判断“删还是不删”背后的需求一致性。Git 只管文件状态，人得管清楚上下文。