应将 core.filemode 设为 false 以忽略文件权限变更，避免跨平台协作中因 100644→100755 等权限变化被误判为修改；该配置仅影响后续状态，需配合 git reset --hard 和 git update-index --chmod=-x 清理已有假修改。
Git 默认会把 100644 → 100755 这类权限变更当成真实修改，这不是 bug，是设计行为；但多数 Web/前端/配置类项目根本不需要跟踪可执行位，必须关掉。
为什么 core.filemode 会突然冒出一堆红色文件？
常见于以下场景：
- 用 VSCode（尤其搭配 WSL 或 Remote-SSH）保存文件时，自动重设了
chmod，比如把.sh外的普通 JS/CSS 文件也标成可执行位 - 在 Windows 上用 Git for Windows 操作后切到 WSL，两个环境对
core.filemode的默认值不一致（Windows 默认false，Linux 默认true） - 团队协作中有人提交了带
100755的静态资源，你拉下来后 Git 认为“权限被改回去了”，于是持续报脏
本质不是文件内容变了，而是 Git 索引里存的权限标记和工作区实际权限对不上。
git config core.filemode false 的作用范围与生效时机
这个配置只影响「后续」的 git status 判断，不会自动修复已有状态。关键点：
Git 提交信息生成器
下载
Git 提交信息生成器。根据代码变更内容自动生成符合 Conventional Commits 规范的提交信息，包含类型、范围、简短描述、详细说明和关联的 Issue/需求号。触发词：生成提交信息、提交信息、commit message、git commit、生成 commit 信息
-
git config core.filemode false：仅当前仓库生效，写入.git/config，适合混合型项目（比如 repo 里既有脚本又有前端资源） -
git config --global core.filemode false：全局生效，所有新 clone 或 init 的仓库都继承，但已存在的仓库需手动进目录运行一次 - 运行后立即生效，无需重启终端或 Git 客户端；验证方式是
git config core.filemode输出false - 如果之前已经
git add过权限变更，该配置不会撤销它们——你得先清理索引里的错误记录
怎么清理已有的权限“假修改”？
别直接 git commit 或 git stash，那会把错误权限固化进历史。正确顺序是：
- 先运行
git reset --hard（确保没未保存的代码改动），清空工作区和暂存区的权限脏状态 - 再执行
git config core.filemode false - 接着用
git update-index --chmod=-x $(git ls-files)批量移除所有文件的可执行位（只改索引，不碰文件本身） - 最后
git status应该显示 clean；如有残留，用ls -l对比具体文件，确认是不是某些插件（如 SFTP 同步工具）还在后台改权限
容易被忽略的兼容性陷阱
最常翻车的地方不在配置本身，而在环境切换和插件干扰：
- WSL 和 Windows 双系统共用同一份代码时，
core.filemode必须分别配——WSL 里设一次，Windows Git Bash 里再设一次，否则切环境就又红 - VSCode 的
files.autoSave+remote.SSH.useLocalServer组合，在旧版中会触发权限重置，建议关掉remote.SSH.useLocalServer或升级到最新版 -
.gitattributes对权限无效，别往里面加* -exec之类——它不处理filemode，那是core层的事 - 如果你真需要保留某些脚本的可执行权限（比如
deploy.sh），不要全局关filemode，而是在关掉后，单独运行git update-index --chmod=+x deploy.sh显式标记
真正卡住人的，往往是改完配置却忘了 git reset --hard 那一步，或者在 WSL 里配了，结果从 Windows 端提交时又冒出来。
