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 只管文件状态，人得管清楚上下文。
