Git对二进制文件冲突静默放弃合并，需手动解决；其依据文件头800字节含\0判定二进制，禁用diff；可用checkout--ours/theirs选版本并git add标记解决；建议预设.gitattributes声明binary避免隐式冲突；高频协作宜用Git LFS替代原生处理。
Git 遇到二进制文件冲突时不会报错，也不会给你任何提示性标记，它只是静默放弃合并，把两个版本都留在工作区——你必须主动识别、手动选择、显式标记解决，否则 merge 永远卡住。
为什么 git diff 对 .psd/.pdf/.xlsx 什么也输出不了
Git 判断二进制的依据是文件头前 800 字节是否含 \0（空字节），不是后缀名。一旦判定为二进制，git diff 就自动禁用内容比对，只显示“Binary files a/file.psd and b/file.psd differ”。这会导致：
-
git status显示both modified，但你看不到任何差异细节 -
git mergetool不弹窗（除非你额外配置了支持二进制的外部工具） - VSCode 的冲突 UI 完全不出现红蓝标记块，连“Accept Current Change”按钮都不会加载
这不是 Git 坏了，是它根本没打算解析这些文件——你得自己承担判断责任。
用 git checkout --ours 或 git checkout --theirs 强制选版本
这是最直接、最安全的解法，适用于明确知道该留哪边的情况（比如你刚改完设计稿，同事改的是旧版）。注意命令末尾的 -- 是必需的，防止路径被误认为参数：
- 保留你当前分支的版本：
git checkout --ours -- path/to/file.psd - 保留对方分支（如
origin/main）的版本：git checkout --theirs -- path/to/report.xlsx - 执行后必须立刻
git add path/to/file.psd，否则 Git 仍认为冲突未解决
别省略 git add：Git 不会因为你覆盖了文件就自动标记为已解决，它只认暂存状态。
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
提前用 .gitattributes 禁用合并，避免“假装能处理”
等冲突发生再手动选，容易漏、容易错、容易忘记 git add。更稳的做法是在项目初期就声明哪些文件永远不该被合并：
- 在仓库根目录新建
.gitattributes - 写入：
*.psd binary、*.xlsx binary、*.sketch binary -
binary关键字等价于-merge -diff，Git 会直接拒绝尝试合并，并在git status中明确标为unmerged
这样下次冲突时，Git 会在终端清晰打印 CONFLICT (binary): Merge conflict in file.psd，而不是含糊的 Auto-merging...，让你一眼识别风险点。
想对比二进制历史变更？别硬扛，上 git lfs
如果团队需要频繁查看 PSD 修改了哪个图层、Excel 更新了哪张表，光靠 binary 声明不够——Git 本身不存二进制 diff，git log -p 永远为空。这时该换思路：
- 运行
git lfs install（一次，全局生效） - 用
git lfs track "*.psd"注册类型，再git add .gitattributes - 后续提交的 PSD 文件会被替换成纯文本指针（如
version https://git-lfs.github.com/spec/v1 oid sha256:abc123...）
指针可被 Git 正常 diff 和三向合并，冲突时你只需确认 SHA 值对应的是哪个正确版本——逻辑回归到文本层面，人脑负担大幅降低。
真正麻烦的从来不是“怎么选”，而是“不知道该选谁”。二进制冲突没有中间态，没有 diff 提示，也没有回退缓冲；一旦 git checkout --ours 覆盖了对方版本，那个字节流就从工作区彻底消失了——所以每次操作前，先用 git show HEAD:file.pdf > backup-local.pdf 和 git show MERGE_HEAD:file.pdf > backup-remote.pdf 备份两份原始文件，是最容易被跳过、也最不该省的一步。
