应执行git update-index --chmod=+x gradlew，使git记录可执行位（变为100755），再提交；否则克隆后因缺少x权限导致./gradlew报permission denied。
git commit 时提示 gradlew 没有执行权限怎么办
Linux/macOS 下，gradlew 是 shell 脚本，必须有 x 权限才能执行。但 Git 默认不跟踪文件权限变更（除非显式设置），克隆后常出现 Permission denied: ./gradlew 错误。
- Git 只记录文件的“可执行位”（executable bit），不记录完整权限（如
rw-r--r--） - Windows 用户提交时，
gradlew往往丢失x位 —— 因为 Windows 文件系统不支持该位，Git 会静默忽略 - macOS/Linux 用户若用 Finder 或某些 IDE 提交，也可能跳过权限设置
如何让 git 正确保存 gradlew 的执行权限
核心是让 Git 记住这个文件是可执行的。只需运行一条命令：
git update-index --chmod=+x gradlew
之后再 git add 和 git commit，Git 就会把可执行位存进索引。验证方式：
-
git ls-files --stage gradlew—— 输出第一列是100755表示带执行权限；100644表示普通文件 - 克隆新仓库后，直接
./gradlew --version应能成功运行 - 别对
gradlew.bat做 chmod，它是 Windows 批处理，不需要也不适用
为什么 .gitattributes 里加 *gradlew* text eol=lf 不够
很多人以为配置行尾符就能解决，但这是两回事：.gitattributes 控制换行符转换（LF/CRLF），不控制可执行位。即使你写了：
*gradlew* text eol=lf
它依然不会让 gradlew 在检出时自动变成可执行。真正起作用的只有 git update-index --chmod 或从已有正确权限的仓库 clone。
CI/CD 流水线里执行失败，是不是权限问题
常见于 GitHub Actions、GitLab CI 等环境：脚本拉下来后 ./gradlew build 报错 Permission denied。原因通常是：
- 上游提交者没运行
git update-index --chmod=+x gradlew - CI 使用的是 shallow clone 或 cache restore，跳过了权限元数据
- 某些 CI 镜像默认 umask 严格，覆盖了文件权限
临时绕过方式（不推荐长期用）：chmod +x gradlew && ./gradlew build。但根本解法仍是确保 gradlew 在 Git 中以 100755 状态存在 —— 这个位一旦入库，所有 clone 都会继承，无需额外修复。
最容易被忽略的一点：团队里只要有一个人在 Windows 上提交过 gradlew，就可能把它“降级”成 100644，后续所有人拉代码都会失效。所以首次初始化项目或升级 Wrapper 后，务必手动确认并固化权限。
