Windows 10 Git Bash中文件权限与Git仓库不一致问题排查

咱们先拆解你遇到的两个核心问题：一是本地修改脚本权限后Git不识别，二是全局与本地core.filemode配置冲突的原因。

一、为什么chmod +x a.sh后Git提示无修改可提交？ #

在Windows环境下，Git的默认行为是忽略文件权限的变化——因为Windows的权限模型和Unix/Linux完全不同，它没有Unix-style的可执行权限位。Git Bash里ls -la显示的可执行权限只是Git Bash模拟出来的，并非Windows系统实际的权限设置。

你看到b.sh在git ls-tree HEAD里是100755，大概率是这个文件在最初被添加到Git仓库时，就通过git update-index --chmod=+x b.sh命令明确标记了可执行权限，Git才会把这个权限信息存在版本库中。而a.sh只是你在本地Git Bash里用chmod +x修改了模拟权限，Git因为默认关闭了权限跟踪（core.filemode=false），所以根本没把这个变化当成需要提交的修改。

解决方法： #

1. 先确保当前仓库开启权限跟踪：

   git config --local core.filemode true
   

2. 用Git命令明确标记a.sh为可执行：

   git update-index --chmod=+x a.sh
   

3. 此时执行git status就能看到权限变化的记录了，提交后推送到远程仓库，Jenkins克隆后a.sh就会拥有可执行权限。

二、全局core.filemode=true但新克隆仓库本地仍为false的原因与解决 #

Git的配置优先级是：本地仓库配置（.git/config）> 全局配置（~/.gitconfig）> 系统配置。

为什么新克隆的仓库会自动把core.filemode设为false？因为Git会根据当前操作系统自动适配这个配置——Windows不支持Unix权限位，所以Git在克隆时会自动在本地仓库配置中写入core.filemode=false，直接覆盖你的全局配置。

解决方法： #

根据你的需求，有几种可选方案：

• 针对单个仓库设置：克隆完成后，进入仓库目录执行：

  git config --local core.filemode true
  

  这个设置只会作用于当前仓库，不会影响其他仓库。
• 克隆时直接指定配置：如果每次克隆都需要开启权限跟踪，可以在克隆命令中添加配置参数：

  git clone -c core.filemode=true <你的仓库地址>
  

  这样克隆出来的仓库默认就会开启权限跟踪。
• 修改Git模板（全局生效）：如果你想让所有新克隆的仓库都默认开启core.filemode=true，可以修改Git的模板配置文件（通常在C:\Program Files\Git\mingw64\share\git-core\templates\.gitconfig，路径可能因Git版本略有不同），在其中添加：

  [core]
      filemode = true
  

  不过要注意，这个设置在Windows环境下可能会导致一些兼容性问题——毕竟Windows本身不识别Unix权限位，本地修改的权限可能无法被系统真正应用，只是Git层面的记录。

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