Git对.psd/.xlsx等二进制文件冲突不报错也不标红，是因为其判定为二进制后直接静默跳过合并，仅保留双方版本并标记为unmerged，不生成冲突标记、不触发VSCode内联提示，也不调用合并驱动。
Git为什么对.psd/.xlsx冲突不报错也不标红
Git遇到二进制文件冲突时根本不会提示“CONFLICT”，也不会在VSCode里渲染\0，不是后缀名；一旦触发，git diff自动禁用内容比对，只输出Binary files a/file.pdf and b/file.pdf differ。
后果很直接：git status显示both modified但你看不到差异；git mergetool不弹窗（除非你额外配了支持二进制的外部工具）；VSCode的冲突UI完全不加载红蓝块，连“Accept Current Change”按钮都不出现。
用git checkout --ours或--theirs强制选版本
这是最常用也最容易出错的操作。命令末尾的--是必需的，否则Git会把路径误认为参数：
- 保留你当前分支的版本：
git checkout --ours -- path/to/logo.sketch - 保留对方分支的版本：
git checkout --theirs -- path/to/report.xlsx
执行后必须立刻git add path/to/logo.sketch，否则Git仍认为冲突未解决——它只认暂存状态，不看你文件内容是否覆盖了。
常见坑点：
- 漏掉
--导致命令失败或误删文件 - 执行
checkout后忘记git add，merge卡住不动 - 在rebase过程中混用
--ours/--theirs含义反转（此时--ours指rebase目标分支）
提前用.gitattributes声明binary避免隐式冲突
等冲突发生再手动选，容易漏、容易错、容易忘git add。更稳的做法是在项目初始化阶段就写好.gitattributes：
*.psd binary *.xlsx binary *.pdf binary *.sketch binary
binary关键字等价于-merge -diff，Git会直接拒绝尝试合并，并在git status中明确标为unmerged，终端也会清晰打印CONFLICT (binary): Merge conflict in file.psd，而不是含糊的Auto-merging。
这个配置能帮你提前暴露风险点，而不是等到CI跑挂才意识到PDF被两人同时改过。
高频协作场景下优先上Git LFS
如果团队频繁修改设计稿、模型文件或大体积文档，原生Git处理二进制就是硬扛——每次git pull都要下载完整文件，历史膨胀快，clone慢，冲突解决全靠人工拍板。
Git LFS把大文件替换成指针，真正内容存在远程LFS服务器：
- 合并时Git只比对指针文本，不再触发二进制判定逻辑
-
git status能准确显示哪个版本被更新，git diff可读 - VSCode等编辑器能正常识别LFS文件变更并触发UI提示
注意：LFS不是银弹。它需要服务端支持（如GitLab Premium、GitHub Pro）、客户端安装git-lfs、以及所有协作者统一启用。没铺开之前，.gitattributes仍是兜底方案。
真正容易被忽略的是：二进制冲突没有“中间态”——你永远只能选A或B，不能像文本那样逐行融合。所有试图“半保留”或“手动编辑.psd”的操作，本质都是在赌运气。
