Git后接收掛鈎不適用於Github

Question

背景和設置

我正在嘗試按照本教程的最后一部分來創建一個接收后的Git鈎子（實際上只是一個例子，其他地方的說明基本上是相同的）。

除了我的本地庫，我有一個GitHub庫設置為遠程稱為中心和生產服務器設置為遠程稱為活 。 我已經准備就緒，可以輕松地從本地存儲庫推送到GitHub，並通過SSH進入生產服務器以從GitHub提取。

目標

我想完全取消后面的步驟，因此我所要做的只是推送到中央存儲庫，生產服務器將在該存儲庫中自動將這些更改拉出-我所看到的一切都告訴我，接收后掛鈎是做到這一點的方式。

問題

由於某種原因，到目前為止，我為使接收后掛鈎正常工作所做的一切嘗試都失敗了。

我post-receive文件存在於我的生產服務器上的.git/hooks/ ，並已使用chmod ug+x使其可執行，是的，“接收后”的拼寫正確。 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掛鈎，但是由於某些原因， 盡管所有指南都指定這是應該工作的方式， 但是當我推送到中央存儲庫時它並未觸發。

我從這些指南中脫穎而出的唯一方法是，服務器上的存儲庫是一種非裸露的存儲庫，但是據我了解到兩者之間的差異，這不應在已建立存儲庫的地方有所作為我可以像往常一樣推拉。

那么，為什么我的接收后掛鈎確實不起作用？

編輯：測試1

將cd行更改為：

cd ~/www.example.com/public_html && touch ./cd_ran_successfully || exit

...然后在本地執行push命令將導致在服務器上沒有cd_ran_successfully創建cd_ran_successfully文件。 但是，登錄到服務器后手動執行文件會創建文件。 這表明共享服務器用於執行文件的用戶/進程存在某種問題，但除此之外我不知道。

Answer 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/

Answer 2

正如jpsalm所指出的那樣，Git掛鈎只能在Git服務器上運行，這在托管網站和CMS（如Wordpress）時通常不常見，尤其是在不太可能進行根訪問的共享服務器上。 Github代替了Git的鈎子，實現了自己的技術版本，稱為webhooks 。

注意：我在下面學到的所有東西都是最近幾個小時左右的研究結果，而這個答案的主要目的是鞏固這些知識，並使我覺得時間並沒有完全浪費。

Webhooks是與API非常相似的技術-API的功能是提供用戶請求的數據，而Webhooks似乎以相反的方式工作：它們偵聽服務器上的指定更改並將這些更改通知用戶。

正如通常應用於Git和Github一樣，webhook會監聽Github上的某個事件（例如git push ，然后將包含該事件的所有詳細信息的POST請求發送到終結點 。 該終結點是服務器上的腳本，編寫該腳本是為了解析POST請求中的JSON，檢查身份驗證，然后在服務器上執行實際上已執行某些操作的腳本-最常見的是從GitHub存儲庫中提取腳本。

Github提供了一個Web接口來創建請求，從而減輕了Webhooks的痛苦，但是仍然讓端點本身（Github混淆性地稱為有效負載，我仍然沒有得到）被編程。除了端點將運行的腳本。

不幸的是，我沒有時間編寫用於使用Bash或其他語言解析JSON的終結點的技術，因此直到有人出現並做到這一點之前，我似乎不得不解決多執行一次push命令。 :)