首页/开发/Git 与协作速查/LFS 的 .gitattributes 条目
进阶与大仓实践69 条

LFS 的 .gitattributes 条目

track 生成的条目形如 <模式> filter=lfs diff=lfs merge=lfs -text:filter 负责指针转换,diff/merge 走 LFS 专用逻辑,-text 关闭行尾转换。

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

LFS 属性条目是什么

.gitattributes 里的 filter=lfs diff=lfs merge=lfs -text 是 LFS 跟踪的落地形式:filter 负责提交时把内容替换为指针、检出时按需还原;diff 与 merge 让差异比较和冲突合并走 LFS 专用逻辑;-text 关闭行尾转换,避免二进制文件在跨平台协作中被改坏。

基本信息

典型条目*.psd filter=lfs diff=lfs merge=lfs -text
filter 作用提交时存指针文本,检出时按需下载还原真实内容
单项检查git check-attr filter -- assets/design.psd
分发方式属性写在仓库的 .gitattributes 里,随克隆自动生效
配套配置仓库根的 .lfsconfig 管 LFS 服务地址等参数,跟踪范围仍由属性文件决定
常见类型设计稿 psd/ai、压缩包 zip、视频 mp4、模型文件等二进制

典型使用场景

  • 新类型大文件入库:先 git lfs track '*.psd' 生成条目,再提交 .gitattributes。
  • 核对某文件是否被 LFS 管理:check-attr 看 filter 值,比肉眼猜文件内容可靠。
  • 历史迁移到 LFS 前:先补好属性条目,再用 migrate 重写历史,顺序不能反。
  • 排查二进制损坏:确认条目包含 -text,缺了它跨平台行尾转换会破坏文件。
  • 团队统一:属性随仓库分发,克隆后所有人生效,无需各自手工配置。

配置与校验

配置与校验
git lfs track '*.psd'                       # 生成条目并写入 .gitattributes
git check-attr filter -- assets/design.psd  # 校验单文件是否走 LFS
cat .gitattributes   # 条目形如:*.psd filter=lfs diff=lfs merge=lfs -text
printf '*.zip filter=lfs diff=lfs merge=lfs -text\n' >> .gitattributes
git add .gitattributes && git commit -m 'chore: track zip via lfs'

四个分量的作用

分量作用去掉之后
filter=lfs提交/检出时做指针与内容转换文件按普通对象存储,LFS 侧缺内容
diff=lfsdiff 走 LFS 语义展示大文件差异退化为不可读的二进制对比
merge=lfs合并交给 LFS 处理二进制冲突更难自动收敛
-text关闭行尾转换跨平台协作可能把二进制改坏
属性一定要写进仓库根的 .gitattributes 才随克隆分发;只配在某台机器的本地属性文件里不会对队友生效,团队统一口径以仓库内文件为准。属性变更只影响之后提交的版本,历史里已存储的内容不会自动切换为 LFS,存量文件需要迁移流程处理。

易错点

  • 手工写属性时漏掉 -text,二进制文件在 Windows 与 Linux 之间被行尾转换,症状是文件损坏且很难追因。
  • 属性模式与实际文件名大小写不一致(如写了 *.PNG 而文件是 .png)会漏跟踪,上传后才发现走的是普通存储。
  • 只加属性不重写历史:旧提交里的大文件仍留在仓库中,体积不会下降,需配合 migrate 或清理流程。
  • 对结构化文本(JSON/YAML)启用 LFS 后 diff/merge 行为改变,评审工具可能无法直接显示差异,确认工具链支持再推广。

数据来源与参考

  • Git LFS 官方文档:Collapse(.gitattributes 说明)
  • Git 官方文档:gitattributes(filter 属性)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌