git status -s 中 UU、AA 等 U 开头的行即冲突文件；git diff --name-only --diff-filter=U 可精准列出未解决冲突路径。
怎么一眼看出哪些文件有冲突
Git 本身不提供“冲突文件列表”这种直白命令，git status 是最可靠入口——但它默认把冲突文件混在“Unmerged paths”里，容易被忽略。关键不是找命令，而是看输出里的明确标识。
- 运行
git status --short（或简写git status -s），冲突文件会显示为UU filename（both modified）、AA filename（added by both）等，U开头的行就是真·冲突 -
git diff --name-only --diff-filter=U更精准，只输出当前未解决冲突的文件路径，适合脚本化或快速复制 - 别信 IDE 右侧“冲突标记”图标——它可能缓存旧状态；终端里跑一遍
git status -s才算数
冲突文件里到底改了哪几块
看到文件名只是第一步，真正卡住的是“这块是谁的、那块该留谁的”。git checkout 和 git ls-files 配合能快速还原上下文，比盲猜靠谱。
- 用
git show :1:filename看 merge 基础版本（common ancestor） -
git show :2:filename看当前分支（HEAD）改动，git show :3:filename看待合并分支改动 - 如果文件太大，别直接开编辑器扫 —— 先用
git diff --no-index /dev/null filename | grep "^+" | head -n 5快速定位新增冲突段落 - 注意：某些编辑器（如 VS Code）的“接受当前/入栈”按钮底层调用的就是
:2和:3，理解这个机制才能手动救场
大量冲突时别一个个 resolve
几十个 UU 文件堆在一起，手动 git add + 编辑器点选效率极低，而且容易漏掉隐式冲突（比如重命名+修改同时发生）。
- 先用
git checkout --ours .或git checkout --theirs .批量“倾向性覆盖”，再针对性修正少数例外文件——前提是你们团队对“ours/theirs”语义有共识 - 对纯文本配置文件（如
package.json），可用git merge-file命令离线合并：git merge-file -p base.txt ours.txt theirs.txt > merged.json，避免编辑器干扰 - 警惕
git reset --hard后重拉——它清不掉 index 中的冲突标记，git read-tree --reset -u HEAD才是彻底重置索引的正确姿势
为什么有些冲突 Git 死活不报，但程序跑不起来
Git 只管行级文本差异，对语义冲突完全无感。函数签名变了、环境变量名重构了、JSON schema 字段删了——这些都不会触发 UU，但足以让 CI 卡住。
- 检查
package-lock.json或yarn.lock是否被不同工具生成，这类文件冲突常表现为“没标记但依赖错乱” - 运行
git ls-files -u查看所有未合并 blob，有时冲突藏在子模块或二进制文件里，git status不显示 - CI 报
Module not found却找不到冲突文件？大概率是import路径在某次 rename 中被部分更新，用git grep -l "old/path" -- "*.js"扫一遍更有效
真正麻烦的从来不是 Git 标出的冲突，而是它沉默放过的那些——尤其当改动跨多个配置层、类型定义和构建脚本时，得靠人眼交叉验证，而不是等工具提醒。
