Git LFS为何可锁定未配置lockable属性的文件？

该现象属于对Git LFS锁机制的理解偏差，既不是功能限制，也不是已知Bug。

• git lfs lock命令本身不会把lockable属性作为加锁的前置校验条件：只要目标文件路径匹配当前仓库配置的LFS追踪规则，且当前操作账号对仓库有对应操作权限，加锁操作就可以正常执行。你的.gitattributes中已经配置*.png filter=lfs diff=lfs merge=lfs -text，所有png文件都属于LFS追踪范围，因此Test.png加锁成功完全符合设计逻辑。
• lockable是LFS锁功能的可选增强配置，而非加锁的必要前提，它的作用只有两个：
  • 自动管控本地文件权限：匹配规则的文件默认设置为只读，只有执行git lfs lock拿到对应锁之后，才会自动开放文件写权限，从本地操作层避免无锁状态下误改文件
  • 推送环节强校验：如果本地修改了匹配lockable规则的文件，但当前账号没有持有对应文件的锁，LFS会直接拦截推送，从流程上阻断无锁修改的代码提交
• 你提到的「Test.png已推送至远程仓库」这个条件不影响加锁结果：哪怕目标文件还未推送到远程，只要路径匹配LFS追踪规则，用户依然可以提前对该路径加锁，提前锁定修改权限。

多数Git LFS教程会将lockable属性和锁功能放在一起讲解，很容易让人形成「没配置lockable就不能加锁」的错误认知。实际上两者是解耦的：

• 不配置lockable时，加锁、解锁、查看锁列表的核心功能完全可以正常使用，只是缺少本地只读限制、推送锁校验两道强制约束，协作全靠团队成员自觉遵守「修改前先拿锁」的约定
• 配置lockable时，只是给锁协作流程加了两层强制校验，不会改变加锁、解锁操作本身的执行逻辑

内容的提问来源于stack exchange，提问作者Mr. Boy