如何修改Git调用钩子的方式？解决非可执行环境钩子执行异常

这问题我碰到过类似的，大概率是托管平台的shell环境限制或者文件系统的noexec挂载属性搞的鬼——就算给钩子加了777权限，也没法直接执行，但通过解释器（比如sh）调用就能跑。咱们直接说怎么修改Git调用钩子的方式来解决：

核心思路 #

Git默认会直接执行钩子文件（比如./post-receive），但如果平台限制了直接执行权限，咱们可以给钩子加一层wrapper脚本，让Git执行这个wrapper，再由wrapper用解释器去跑实际的部署逻辑。

具体解决方案 #

方案1：用Wrapper脚本中转调用 #

1. 先把你原来的post-receive脚本重命名，比如改成post-receive-deploy：

   mv hooks/post-receive hooks/post-receive-deploy
   

2. 新建一个名为post-receive的文件，作为Git调用的入口，内容如下：

   #!/bin/sh
   # 直接用sh解释器执行实际的部署脚本
   exec sh "$(dirname "$0")/post-receive-deploy"
   

3. 给这个新的post-receive加执行权限：

   chmod +x hooks/post-receive
   

这样Git触发钩子时，会执行这个wrapper脚本，再由它调用sh去跑你的实际部署逻辑，绕开了直接执行的权限限制。

方案2：调整脚本的Shebang行 #

如果是脚本开头的解释器路径不对导致的问题，可以先确认托管平台的shell路径：

which sh

拿到路径（比如/usr/bin/sh）后，把你原来的post-receive脚本第一行的shebang改成这个路径，比如：

#!/usr/bin/sh

再重新加权限试试：chmod +x post-receive，有时候平台的默认/bin/sh路径和你脚本里写的不一致，也会导致直接执行失败。

验证方法 #

可以手动模拟Git的调用方式测试：

./hooks/post-receive

如果能正常运行，就说明修改生效了；如果还是不行，大概率是平台的安全策略（比如SELinux、AppArmor）限制，这时候可能需要联系托管平台确认钩子脚本的执行权限规则。

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