git status可一眼识别二进制冲突文件，即Unmerged paths中显示“both modified”但无文本冲突标记的文件；需用git checkout --ours/--theirs手动覆盖并git add确认，或通过git ls-files -s比对哈希与大小判断真改动。
git status 一眼识别哪些是二进制冲突文件
执行 git merge 或 git pull 后，先别急着打开编辑器。直接运行 git status，重点看 Unmerged paths 区域里带 both modified 但没有文本冲突标记（如 ）的文件——这类就是二进制冲突。
常见表现：
-
both modified: assets/logo.psd（PSD 文件无行级差异，Git 只能报冲突） -
both modified: data/report.xlsx（Excel 文件内容不可 diff，大小或哈希值不同即冲突） -
deleted by them: design/mockup.sketch（对方删了，你改了，Git 不知道该保留文件还是删掉）
注意：二进制文件不会出现冲突标记，git diff 也基本输出空或乱码，这是正常现象，不是命令错了。
用 git checkout --ours / --theirs 精准覆盖单个文件
对明确知道该留哪边的二进制文件，不用打开图形工具，直接命令行解决：
-
git checkout --ours -- assets/logo.psd→ 保留当前分支（HEAD）版本，丢弃对方修改 -
git checkout --theirs -- data/report.xlsx→ 保留被合并分支的版本，丢弃本地修改 - 执行后必须立刻
git add assets/logo.psd，否则 Git 仍认为未解决
⚠️ 关键提醒：--ours 和 --theirs 在 git rebase 中含义反转（此时 --ours 指的是被 rebase 的原始分支），但只要你在 git merge 流程里，就按字面理解：ours = 当前分支，theirs = 要合并进来的分支。
用 git ls-files -s 查看二进制文件真实变更点
当拿不准该选哪边时，别靠猜。先查两个版本的 object hash 和 size 差异：
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
-
git ls-files -s assets/logo.psd→ 输出三列：mode type hash stage，其中hash是 Git 存储的对象 ID - 对比
HEAD:assets/logo.psd和MERGE_HEAD:assets/logo.psd的 hash 值是否一致；不一致说明内容真变了 -
git cat-file -s查各自体积，若相差极大（比如一个 2MB、一个 15MB），大概率是重新导出导致元数据膨胀，而非实质性修改
这步能帮你区分「真改动」和「假冲突」（例如只是软件版本升级导致时间戳/压缩方式变化）。
跳过自动合并，用 --no-commit + reset 控制流程
如果一次合并涉及大量二进制文件（如设计稿、模型、音视频），又不确定是否全要覆盖，推荐分步操作：
-
git merge --no-commit feature-design→ 拉入变更但不提交，所有冲突文件已处于工作区，且带完整内容 - 此时运行
git status，可逐个检查每个二进制文件是否真需要处理 - 若发现误合并，直接
git reset --hard HEAD回退，工作区干净如初 - 若只想保留部分，对每个文件单独执行
git checkout --ours或git checkout --theirs，再git add
这个组合在 CI 脚本或批量同步资产目录时特别稳——它把“合并”和“提交”解耦，给你留出人工判断窗口，而不是让 Git 自动 commit 一堆没确认的二进制覆盖。
二进制冲突最危险的不是难解决，而是容易忽略“谁改了什么”。git ls-files -s 和 --no-commit 这两个动作，比盲目点“接受传入更改”安全十倍。
