首页/开发/Git 与协作速查/二进制文件冲突处理
合并变基与冲突71 条

二进制文件冲突处理

二进制文件无法逐行合并,冲突时只能整份二选一;配合 .gitattributes 标记 binary 或为特定类型指定专用合并驱动。

Git 与协作速查开发更新于 2026-10-13

二进制文件冲突是什么

图片、压缩包、Office 文档、编译产物这类二进制文件无法按行合并,Git 只能判断「两边都改了」,冲突时只能整份二选一。要让它正确处理,需要在 .gitattributes 中声明 binary 属性,或者为特定文件类型指定专用的合并驱动。

基本信息

冲突表现git status 显示 both modified,diff 只提示「二进制文件不同」
处理方式用 git checkout --ours 或 --theirs 取一侧,再 git add 标记已解决
预防手段在 .gitattributes 标记 binary,跳过行级比较与文本转换
体积控制大二进制文件应交给 Git LFS 或独立制品仓库,避免仓库膨胀
平台差异各系统行为一致,Windows 与 Linux 无差别

典型使用场景

  • 设计稿与图片资源被多人同时替换
  • 游戏项目的美术、音频资源版本更新
  • Office 文档、演示文稿在仓库内协作
  • 编译产物或安装包被误提交进仓库
  • 机器学习数据集或模型文件按版本管理

常用示例

常用示例
git status                                # 看到 both modified,说明两侧都改过
git diff --stat                           # 二进制文件只列文件名,没有逐行差异
git checkout --ours -- assets/logo.png     # 保留当前分支的版本
git add assets/logo.png                   # 标记该文件冲突已解决
git commit                                # 完成合并
# 预防:声明二进制类型,避免后续再尝试行级合并
printf '*.png binary\n*.xlsx binary\n' >> .gitattributes

取用命令与适用场景

命令取哪一侧何时使用
git checkout --ours -- 文件当前分支(合并目标)我方版本更新,对方是误改
git checkout --theirs -- 文件被合并进来的分支确认对方版本才是最终结果
git checkout -m -- 文件重建冲突标记想撤掉手工编辑重新处理
binary 属性只影响比较与合并行为,不改变存储方式:它不会压缩内容,也不减少仓库体积,大文件仍然需要 LFS 或制品库来控制。
变基过程中两侧的含义会反转:变基时被取用的「theirs」指你正在重放的提交,「ours」指被重放的基线,动手前先确认当前是哪一种操作。

易错点

  • 用文本编辑器硬开二进制文件「解决冲突」会把文件写坏,往往到运行或打开时才发现,务必用取一侧命令处理
  • 声明 binary 后 Git 不再尝试任何自动合并,两人同时改动同一文件必然冲突,需要配合「同一时段只有一人改该文件」的约定
  • 把编译产物、依赖包提交进仓库,每次构建都产生新的二进制差异,仓库体积迅速增长,应改为构建时生成或走制品库
  • 取一侧前不确认对方改动内容,可能丢掉同事辛苦调整的设计稿或排版,取用时先对比文件大小与修改时间

数据来源与参考

  • Git 官方文档:gitattributes(binary/merge 驱动)
  • Git 官方文档:git-checkout(--ours/--theirs)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌