Git仅识别带执行位的文件权限变更，能否不设执行位完成权限设置？

现象原因 #

Git原生设计仅跟踪文件所有者可执行位的状态变更，不会记录文件的读/写权限，也不会记录组用户、其他用户的任何权限位。你遇到的现象完全符合该设计逻辑：

• 首次clone后无执行位的文件，你将权限从600改为644，变更的是读权限位，Git未存储这类权限的基准值，因此不会识别为变更
• 原本带执行位的文件，你将权限从700改为644，变更了所有者执行位，Git能识别到该差异，因此显示为modified
• 你将所有文件改为744时，相当于给所有无执行位的文件新增了所有者执行位，Git检测到所有文件的执行位都发生了变更，因此全部显示为modified

解决方案 #

场景1：仅需统一仓库所有文件权限为644，无需跟踪后续细粒度权限变化 #

按以下步骤操作即可：

1. 执行命令移除所有文件的可执行位，设置权限为644：

find . -type f -not -path './.git/*' -exec chmod 644 {} +

2. 此时Git已识别到原带执行位的文件变更，直接提交即可：

git add .
git commit -m "统一所有普通文件权限为644，移除可执行位"

3. 如果后续不想本地文件系统的权限变更被Git检测到，可关闭当前仓库的执行位跟踪配置（该配置仅本地生效，不会同步到远程）：

git config core.fileMode false

场景2：需要跟踪所有文件的细粒度权限（读/写/执行、全用户组权限） #

Git本身不原生支持该需求，可通过Git钩子变相实现：

1. 新增pre-commit钩子，提交前自动将当前所有文件的权限列表导出到.permissions文件，随代码一起提交：

# pre-commit钩子内容示例
find . -type f -not -path './.git/*' -exec stat -c "%a %n" {} \; > .permissions
git add .permissions

2. 新增post-checkout、post-merge钩子，拉取代码后自动读取.permissions文件恢复所有文件的对应权限：

# 钩子恢复权限内容示例
while read perm file; do
  [ -f "$file" ] && chmod "$perm" "$file"
done < .permissions

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