Git LFS跟踪规则不随分支变化，因其依赖仓库级的.gitattributes文件，该文件被所有分支共享且在提交后生效；LFS客户端仅依据当前HEAD中的.gitattributes决定是否拦截文件，不存在分支专属开关。
Git 本身不支持“按分支自动启用 LFS”——LFS 跟踪规则是仓库级的，由 .gitattributes 文件统一定义，与分支无关。你不能让 main 分支用 LFS 存 .zip，而 dev 分支不用 LFS 或换用别的规则。
为什么 git lfs track 规则不随分支变化？
LFS 的核心机制依赖 .gitattributes 文件，它被 Git 视为普通 tracked 文件，一旦提交，就成为所有分支共享的配置。Git 在 checkout、merge、rebase 时不会动态切换 LFS 行为；LFS 客户端只在执行 git add / git commit / git push 时，根据当前工作目录下有效的 .gitattributes（即 HEAD 所在提交里的版本）决定是否拦截文件、生成指针。
这意味着：
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 如果
.gitattributes在main中写了*.bin filter=lfs diff=lfs merge=lfs -text，那只要该文件存在于任何分支的 HEAD 中，该规则就生效 - 如果
dev分支删掉了这行规则，但你从main切过去再git add big.bin，LFS 不会介入——因为当前.gitattributes里没这条规则 - 没有“分支专属 LFS 开关”，也没有
git config --local lfs.branch-aware true这种配置项
想实现“不同分支处理大文件方式不同”，实际可行的做法
只能靠人工或脚本控制 .gitattributes 内容，并配合分支生命周期管理。常见场景和对应操作：
-
新功能分支暂不走 LFS：在创建
feature/audio前，先 checkout 到该分支，手动删掉.gitattributes中音频相关规则（如*.wav filter=lfs），再提交。后续在这个分支上git add的.wav就走原生 Git -
发布分支强制 LFS：在
release/v2.0分支中，确保.gitattributes包含所有生产级大文件规则（models/*.pt、assets/*），并禁止修改该文件（可通过 CI 检查git lfs track输出是否匹配预期） -
避免规则冲突：不要在不同分支里对同一后缀做相反配置（比如
main写*.pdf filter=lfs，docs分支写*.pdf -filter），否则 merge 时.gitattributes冲突难解，且 LFS 行为不可预测
git lfs ls-files 显示结果为何看起来“因分支而异”？
这不是规则变了，而是当前工作区里实际存在的、被 LFS 管理的文件不同：
-
git lfs ls-files只列出当前 HEAD 提交中、满足当前.gitattributes规则且已通过git add加入索引的大文件 - 如果
dev分支还没添加任何.psd，即使.gitattributes有*.psd规则，git lfs ls-files也为空 - 如果
main已提交过design.psd，而dev是从main分出来的但尚未修改该文件，git lfs ls-files在两个分支下会显示相同内容 - 真正影响显示的是：文件是否在当前分支 HEAD 中 + 是否匹配当前
.gitattributes+ 是否已git add过
真正需要区分分支行为时，别指望 LFS 自动适配——得靠人盯住 .gitattributes 的提交历史，以及每次切分支后确认 git lfs track 输出和 git lfs ls-files 结果是否符合预期。这点容易被忽略，但恰恰是多人协作中 LFS 出问题的最常见源头。
