遇到CONFLICT (add/add)或CONFLICT (modify/delete)需先明确语义意图：add/add须判断是否重复创建并选保留或合并；modify/delete需确认删除是误操作还是重构，再决定恢复文件并应用修改或执行git rm。
遇到 CONFLICT (add/add) 或 CONFLICT (modify/delete) 怎么办
这类冲突不是代码行级的，而是 Git 对文件“存在状态”产生分歧：比如一个分支新增了 config.json，另一个分支删掉了它；或者两个分支各自新建了同名但内容不同的 README.md。Git 无法自动判定该保留、该丢弃、还是该合并，直接卡在 Unmerged paths 状态。
解决关键不是改内容，而是先明确语义意图：
-
add/add：两个分支都新增了同名文件 → 检查是否重复创建，选一个保留，或手动合并内容后删掉另一份 -
modify/delete：A 分支改了utils.js，B 分支删了它 → 问清楚：删除是误操作？还是重构移除？若应保留，就恢复文件并应用修改；若应删除，就git rm utils.js -
rename/rename或rename/delete：通常出现在重命名+编辑混合操作中 → 用git status -v查看实际重命名路径，再决定用git mv对齐，或手动重建文件结构
二进制文件（图片、PDF、字体）冲突不能用文本标记解决
Git 对二进制文件只记录“有改动”，不解析内容，所以不会插入 <<<<<< HEAD 这类标记，但 git status 仍会报 both modified。此时强行 git add 会把当前工作区版本当成“解决后”提交，极易覆盖他人改动。
正确做法是停在这里，人工确认：
- 用
git log --oneline --merge config/logo.png看两个分支各自最后一次修改这个文件的提交，比对修改意图 - 如果只是不同尺寸的同一张图，选更合适的一版，
git checkout <commit-hash> -- logo.png拉取指定版本，再git add - 如果是设计稿迭代（v1.png → v2.png），建议重命名区分，避免下次再冲突，例如改为
logo-v2.png并更新引用处
git merge --abort 不是万能回退键
很多人以为只要没 git commit 就能无损撤回，但 git merge --abort 只在合并尚未产生任何索引变更时有效。一旦你执行过 git add（哪怕只加了一个文件），Git 就认为你在“主动解决”，--abort 会失败并提示 fatal: You have not concluded your merge (MERGE_HEAD exists)。
真要放弃，得按状态分情况处理：
- 还没
git add：直接git merge --abort - 已
git add但没git commit：先git reset清暂存区，再git checkout -- .丢弃所有工作区修改，最后git merge --abort - 已
git commit：只能git reset --hard HEAD~1（慎用，会丢掉这次提交）
用 git diff --name-only --diff-filter=U 快速定位未解决文件
合并冲突多时，git status 输出容易被其他信息干扰。直接运行 git diff --name-only --diff-filter=U 能干净列出所有 Unmerged 文件，一行一个，方便逐个打开处理。
配合 shell 可批量检查（谨慎使用）：
git diff --name-only --diff-filter=U | xargs -I {} sh -c 'echo "=== {} ==="; head -n 5 {}'注意：这个命令只读前 5 行，避免大文件卡住；真正解决时仍需人工判断上下文，尤其注意 add/add 类型文件可能根本没冲突标记，但 Git 已把它列为未合并。
真正的难点不在语法，而在理解每个冲突背后的人为意图——谁删文件？谁重命名？为什么加同名配置？这些没法靠命令自动推断，得翻提交记录、问协作者、看 issue 描述。工具只是放大你的判断，不是替代它。
