我正在尝试遵循the last part of this tutorial here来创建接收后Git钩子（真的只是一个例子，其他地方的指令基本上是相同的）。
除了本地存储库外，我还有一个GitHub存储库，它设置为名为 central 的远程服务器，以及一个生产服务器，其设置为名为 live 的远程服务器。 我已经准备就绪，可以轻松地从本地存储库推送到GitHub，并通过SSH进入生产服务器以从GitHub提取。
我想完全取消后面的步骤，因此我要做的就是将其推送到中央存储库，生产服务器将从该存储库中自动提取这些更改-我所看到的一切都告诉我，接收钩子就是这样做的方法。
由于某种原因，到目前为止，我为使接收后挂钩正常工作所做的一切尝试都失败了。
我的post-receive文件存在于我的生产服务器中的.git/hooks/中，已通过chmod ug+x使其可执行，是的，“ post-receive”的拼写正确。 post-receive文件包含以下Bash代码：
#!/bin/sh
cd ~/www.example.com/public_html || exit
unset GIT_DIR
git pull central master
exec git update-server-info
我什至可以通过SSH进入生产服务器并手动执行post-receive钩子，但是由于某些原因，当我推送到中央存储库时，它并不会被触发，尽管所有指南都指定这是工作方式。
我从这些指南中脱颖而出的唯一方法是服务器上的存储库是一个非裸露的存储库，但是据我了解到两者之间的差异，这应该不会改变它的位置已经确定我可以像往常一样推拉。
那为什么我的接收后挂钩确实不起作用？
将cd行更改为：
cd ~/www.example.com/public_html && touch ./cd_ran_successfully || exit
...然后在本地执行push命令将导致在服务器上没有创建cd_ran_successfully文件。但是，登录到服务器后手动执行文件会创建文件。这表明共享服务器用来执行文件的用户/进程存在某种问题，但除此之外，我不知道。
答案 0 :(得分：1)
接收后挂钩是服务器端的挂钩，它必须在您的git服务器上。
通常，要运行自定义钩子，您将需要托管自己的git服务器。听起来像您想要的那样，您需要将生产服务器设置为还托管一个git服务器，您可以将其设置为可推送到的另一个git远程服务器。
然后，您可以设置后接收以根据需要部署文件。
或者，您可以设置一个预推送脚本，以使您的产品服务器知道有可用的更新，尽管它很hacky。
预推：
#!/usr/bin/env bash
ssh user@prod "/home/user/my_script.sh &"
my_script.sh
#!/usr/bin/env bash
# Wait for push to go through
sleep(25)
cd git_dir && git pull
# Deploy
cp git_dir/binary /usr/bin/
答案 1 :(得分：0)
正如jpsalm所指出的那样，Git钩子只能在Git服务器上运行，这在托管网站和CMS（如Wordpress）时通常不常见，尤其是在不太可能进行root访问的共享服务器上。 Github代替了Git的钩子，实现了自己的称为webhooks的技术版本。
N.B。我在下面学到的所有东西都是最近几个小时左右的研究结果，而这个答案的主要目的是为了巩固这些知识，并使我感到时间并没有完全浪费。 < / p>
Webhooks与API非常相似-API的功能是提供用户请求的数据，而Webhooks似乎是相反的：它们侦听服务器上的指定更改并将这些更改通知用户。
通常在Git和Github上使用，一个Webhook侦听Github上的事件，例如git push，然后将包含该事件的所有详细信息的POST请求发送到端点。该终结点是服务器上的脚本，编写该脚本是为了解析POST请求中的JSON，检查身份验证，然后在服务器上执行实际上已执行某些操作的脚本-最常见的是从GitHub存储库中提取脚本。
Github通过提供一个用于创建请求的Web界面来缓解Webhooks的痛苦，但这仍然使端点本身（Github令人困惑地称为有效载荷，我仍然没有得到）除了端点将运行的脚本之外，还可以进行编程。
不幸的是，我没有时间编写用于使用Bash或其他语言解析JSON的终结点的技能，因此直到有人出现并做到这一点，我才知道准备执行另外的push命令。 ：）