为什么git checkout会将未跟踪文件权限改为只读？如何防范该问题？

• 核心诱因是你的.gitattributes配置中全局启用了lockable属性：第一行规则* filter=lfs diff=lfs merge=lfs -text lockable用通配符*匹配仓库目录下所有文件，包括未被Git跟踪的文件。
• Git LFS的lockable属性默认逻辑是：所有标记为lockable的文件默认设为只读，避免用户未申请锁就修改文件产生提交冲突。
• 执行git checkout操作时会触发工作区文件属性刷新逻辑，Git会扫描所有匹配规则的文件统一调整权限，哪怕文件未被跟踪也会被命中修改。
• 你配置的core.filemode=false符合Windows环境的特征，Windows平台下Git对文件权限的处理逻辑会放大这个问题的影响。

方案1：缩小lockable属性匹配范围（最推荐） #

移除全局规则里的lockable参数，仅给需要独占编辑的二进制文件单独配置lockable属性，示例：

# 原全局规则去掉lockable
* filter=lfs diff=lfs merge=lfs -text
# 仅给需要锁的二进制文件加lockable
*.psd lockable
*.bin lockable
*.prt lockable

修改后重新执行git checkout即可恢复正常，未跟踪的普通文件不会再被强制改只读。

方案2：关闭LFS自动设置只读的逻辑 #

执行以下Git配置命令，禁用LFS自动把lockable属性文件设为只读的逻辑：

git config lfs.setLockableReadOnly false

该配置生效后，Git LFS不会主动修改工作区文件权限，仅保留锁的冲突校验能力，适合不需要严格权限管控的场景。

方案3：把不需要跟踪的文件加入.gitignore #

将未跟踪且不需要被Git管理的文件路径加入.gitignore，Git会忽略对这类文件的所有属性处理，自然也不会修改它们的权限。

临时补救方案 #

如果只是临时需要修改被误设为只读的文件，手动修改文件权限恢复可写即可：Windows下可以右键文件取消只读勾选，类Unix环境执行chmod +w 文件名。

内容的提问来源于stack exchange，提问作者gitrdone