git status 或 git diff --name-only --diff-filter=U 可快速定位冲突文件，前者列出 Unmerged paths 下的 both modified 文件，后者精准输出未合并内容冲突文件，避免 IDE 或 GUI 漏检。
git merge 时提示 “CONFLICT (content)” 怎么快速定位冲突文件
冲突发生后，git status 是最直接的入口，它会明确列出 Unmerged paths 下的文件，并标注为 both modified。不要依赖 IDE 的高亮或 Git GUI 的模糊提示——它们可能漏掉子模块或未跟踪但被合并逻辑涉及的路径。
更可靠的做法是执行：
git diff --name-only --diff-filter=U
这个命令只输出真正存在内容冲突（U 表示 unmerged）的文件，不含已解决或仅本地修改的条目。如果结果为空，说明冲突其实已被部分解决，或者你当前不在目标分支上（比如误在 main 上运行了 git merge feature 但没切回 feature）。
看到 >>>>>> commit-hash？
这是典型的“手动编辑冲突标记但删错了边界”的表现，不是 Git 没生成，而是你或某次 git add 后又手改了文件。Git 写入冲突标记时严格遵循三段式：<<<<<< HEAD、=======、>>>>>> <commit-hash>。任意缺失都会让 git checkout --ours/--theirs 失效，也会导致 git add 拒绝暂存（报错 fatal: 'file' is not in the index）。
- 用
git checkout --conflict=diff3 file重置并强制补全三段标记（需 Git 2.30+） - 若版本较旧，先
git restore --staged file，再git checkout -m file强制还原冲突状态 - 检查编辑器是否启用了“自动删除尾部空行”或“保存时格式化”，这类功能常吃掉
=======行
git merge --abort 失败：提示 “You have not concluded your merge (MERGE_HEAD exists)”
这说明 Git 认为你还在合并过程中，但某些状态文件损坏或残留。常见于强制关机、IDE 异常退出后。别急着删 .git/MERGE_HEAD——直接删可能让 Git 丢失上下文，后续 git pull 或 git rebase 出错。
安全做法是分两步清理：
- 运行
git merge --abort；若失败，再执行git reset --merge（兼容性更好，Git 2.19+ 默认行为） - 仍卡住就检查
.git/MERGE_MODE是否存在，有则删；再确认.git/CHERRY_PICK_HEAD是否误存（rebase 中断遗留） - 最后验证：运行
git status应显示干净工作区，且git rev-parse MERGE_HEAD返回错误而非哈希值
为什么 git mergetool 不启动或卡在 vimdiff 界面不动
git mergetool 依赖配置项 merge.tool 和对应工具的可执行路径。默认 vimdiff 在无 GUI 环境下会阻塞终端，尤其当 $TERM 未设为 xterm-256color 或类似值时，根本进不了交互模式。
快速验证和修复：
- 运行
git config --get merge.tool，若为空，设为vimdiff或vscode（后者需装code --install-extension ms-vsliveshare.vsliveshare并启用git config --global merge.tool vscode） - 对 vimdiff，加参数强制前台：
git mergetool --no-prompt --tool=vimdiff - 若用 VS Code，确保
code --wait可执行；否则 mergetool 会启动后立刻退出，留下未解决标记
冲突本质是两个变更集在相同代码段的不可调和修改，没有“全自动解法”。最省时间的方式，永远是看 git log --oneline --graph --all 先搞清谁改了什么，而不是盯着冲突标记硬猜。多人协作中，提前用 git pull --rebase 降低合并频次，比练熟 mergetool 更治本。
