git分支切换因文件权限变动失败的本质是core.filemode=true时git忠实地还原目标分支记录的可执行位，而系统或配置不支持；解决方法是设git config [--global] core.filemode false，使git忽略权限变化。
Git分支切换因文件权限变动失败，本质不是Git“出错”，而是它在忠实地还原目标分支记录的可执行位（mode），而你的系统或配置不配合——解决它不需要暴力清理，只需对齐三方行为：Git、文件系统、用户权限。
git checkout 报错 Permission denied 或 mode 变更后 status 显示大量修改
常见现象是执行 git checkout feature 后卡住，或成功切换但 git status 突然列出几十个文件“modified: xxx”，实际只是权限位从 100644 变成 100755（或反之）。这不是文件内容变了，是 Git 记录的可执行位与当前工作区不一致。
- 先确认是不是 mode 问题：
git ls-files -s <filename></filename>查看该文件在当前分支的 Git 内部 mode 记录 - 对比你本地文件的实际权限：
ls -l <filename></filename>，若二者不一致（比如 Git 记的是100755，但ls显示-rw-r--r--），说明 Git 没能成功应用权限 - 根本原因通常是：
core.filemode配置为true，但你的 umask（如0022）阻止了写入组/其他用户的执行位，或文件系统（如 NTFS、某些挂载卷）不支持 Unix 权限
core.filemode false 能解决大部分场景
这是跨平台协作中最稳妥的默认设置。设为 false 后，Git 彻底忽略工作区文件的权限变化，不再把它当“修改”，也不会尝试还原 mode —— 既避免误报，也绕过系统限制。
- 查看当前值：
git config core.filemode - 全局关闭（推荐）：
git config --global core.filemode false - 仅对当前仓库关闭：
git config core.filemode false - 注意：这不会改变已提交的 mode 记录，只影响 Git 是否检测本地变化；远程 clone 新仓库时，该配置需提前设置或由团队统一约定
容器或共享目录中切换失败：.git/index.lock Permission denied
在 Docker 容器、WSL、NAS 挂载目录等场景下，git checkout 常因用户 UID/GID 不匹配，导致无法写入 .git/index 或 .git/index.lock，直接报 Permission denied。
- 检查当前用户和
.git目录属主：id和ls -ld .git - 若属主是宿主机用户（如 UID 1000），而容器内运行的是 UID 1001，则需启动容器时指定匹配 UID：
docker run -u $(id -u):$(id -g) ... - 临时修复（不推荐长期用）：
sudo chown -R $USER:$USER .git，但下次挂载可能又失效 - 避免 hooks 自动改权限：不要在
.git/hooks/post-checkout里写chown，它会覆盖容器用户上下文，且每次切换都触发，反而加剧权限混乱
为什么 git stash / git add 不能解决权限问题？
因为 git stash 和 git add 只处理文件内容变更，不触碰 mode 记录。即使你暂存了所有内容，切换分支时 Git 仍会尝试按目标分支的 mode 设置文件权限——如果系统不允许，就会失败或静默降级（如把 100755 写成 100644），后续再切回来又触发新一轮差异。
- 真正要干预的点只有三个：Git 的
core.filemode行为、文件系统是否支持权限位、用户是否有权写入目标路径 - 别指望
git clean -f或git reset --hard修复权限——它们清的是内容，不是权限元数据 - 最易被忽略的是：Windows 用户用 WSL 或 Git for Windows 时，NTFS 挂载点默认不保存 exec bit，此时必须设
core.filemode false，否则每次切换都在“假冲突”中循环
