Git

git-receive-pack は 2.43.0 で最終更新されました

名前

git-receive-pack - リポジトリにプッシュされたものを受け取る

概要

git receive-pack <git-dir>

説明

*git send-pack* によって呼び出され、リモート側から送られた情報でリポジトリを更新します。

このコマンドは通常、エンドユーザーによって直接呼び出されることはありません。プロトコルのUIは*git send-pack*側にあり、このプログラムのペアはリモートリポジトリへの更新をプッシュするために使用されることを意図しています。プル操作については、git-fetch-pack[1]を参照してください。

このコマンドは、リモート側でsha1参照 (heads/tags) の作成とファストフォワードを許可します (厳密に言えば、*git-receive-pack*が実行されるのはローカル側ですが、send-pack側を使用しているユーザーにとってはリモートを更新しています。混乱しましたか？)

Documentation/howto ディレクトリには、update および post-update フックの使用に関する他の実用的な例があります。

*git-receive-pack* は receive.denyNonFastForwards 設定オプションを尊重します。これは、ファストフォワードではない場合に参照の更新を拒否するかどうかを指示します。

その動作を調整するために、他のreceive.*設定オプションが多数利用可能です。git-config[1]を参照してください。

オプション

<git-dir>: 同期対象のリポジトリ。
--http-backend-info-refs: git-http-backend[1]によって、$GIT_URL/info/refs?service=git-receive-pack リクエストを提供するために使用されます。git-upload-pack[1]の--http-backend-info-refsを参照してください。

PRE-RECEIVE フック

参照が更新される前に、$GIT_DIR/hooks/pre-receive ファイルが存在し、実行可能であれば、引数なしで一度呼び出されます。このフックの標準入力は、更新される参照ごとに1行です。

sha1-old SP sha1-new SP refname LF

refname の値は $GIT_DIR に対する相対パスです。例えば、master head の場合は「refs/heads/master」です。各 refname の前の2つの sha1 値は、更新前後の refname のオブジェクト名です。作成される参照は sha1-old が 0{40} に等しくなり、削除される参照は sha1-new が 0{40} に等しくなります。それ以外の場合、sha1-old と sha1-new はリポジトリ内の有効なオブジェクトである必要があります。

署名付きプッシュを受け入れる際 (git-push[1]を参照)、署名付きプッシュ証明書はブロブに保存され、そのオブジェクト名については環境変数GIT_PUSH_CERTを参照できます。例についてはpost-receiveフックの説明を参照してください。さらに、証明書はGPGを使用して検証され、結果は以下の環境変数としてエクスポートされます。

GIT_PUSH_CERT_SIGNER

プッシュ証明書に署名したキーの所有者の名前とメールアドレス。

GIT_PUSH_CERT_KEY

プッシュ証明書に署名したキーのGPGキーID。

GIT_PUSH_CERT_STATUS

プッシュ証明書のGPG検証ステータス。git logファミリーコマンドの%G?フォーマットで使用されるものと同じニーモニックを使用します (git-log[1]を参照)。

GIT_PUSH_CERT_NONCE

プロセスが署名者にプッシュ証明書に含めるように要求したナンス文字列。これがプッシュ証明書の「nonce」ヘッダーに記録された値と一致しない場合、その証明書が別の「git push」セッションから再生されている有効なものである可能性を示している場合があります。

GIT_PUSH_CERT_NONCE_STATUS

UNSOLICITED: 「git push --signed」は、こちらが要求していないにもかかわらずナンスを送信しました。
MISSING: 「git push --signed」はナンスヘッダーを送信しませんでした。
BAD: 「git push --signed」は不正なナンスを送信しました。
OK: 「git push --signed」は、こちらが要求したナンスを送信しました。
SLOP: 「git push --signed」は、今回要求したナンスとは異なるが、以前のセッションで要求したナンスを送信しました。環境変数GIT_PUSH_CERT_NONCE_SLOPを参照してください。

GIT_PUSH_CERT_NONCE_SLOP

「git push --signed」は、今回要求したナンスとは異なるが、開始時刻が現在のセッションとこれだけの秒数異なる別のセッションで要求したナンスを送信しました。GIT_PUSH_CERT_NONCE_STATUSがSLOPである場合にのみ意味があります。git-config[1]のreceive.certNonceSlop変数についても読んでください。

このフックは、refnameが更新される前、およびファストフォワードチェックが実行される前に呼び出されます。

pre-receive フックがゼロ以外の終了ステータスで終了した場合、更新は実行されず、update、post-receive、および post-update フックも呼び出されません。これは、更新がサポートされない場合にすぐに中止するのに役立ちます。

下記の隔離環境に関する注記を参照してください。

UPDATE フック

各参照が更新される前に、$GIT_DIR/hooks/update ファイルが存在し、実行可能であれば、参照ごとに一度、3つの引数で呼び出されます。

$GIT_DIR/hooks/update refname sha1-old sha1-new

refname パラメータは $GIT_DIR に対する相対パスです。例えば、master head の場合は「refs/heads/master」です。2つの sha1 引数は、更新前後の refname のオブジェクト名です。このフックは refname が更新される前に呼び出されるため、sha1-old が 0{40} (つまり、まだそのような参照がない) であるか、refname に記録されているものと一致する必要があります。

指定された参照の更新を許可しない場合は、フックはゼロ以外のステータスで終了する必要があります。そうでない場合は、ゼロで終了する必要があります。

このフックの成功した実行 (ゼロの終了ステータス) は、参照が実際に更新されることを保証するものではなく、単なる前提条件です。そのため、このフックから通知 (例: メール) を送信することは良い考えではありません。代わりにpost-receiveフックの使用を検討してください。

POST-RECEIVE フック

すべての参照が更新された後 (または更新が試行された後)、いずれかの参照の更新が成功し、$GIT_DIR/hooks/post-receive ファイルが存在し、実行可能であれば、引数なしで一度呼び出されます。このフックの標準入力は、正常に更新された各参照につき1行です。

sha1-old SP sha1-new SP refname LF

refname の値は $GIT_DIR に対する相対パスです。例えば、master head の場合は「refs/heads/master」です。各 refname の前の2つの sha1 値は、更新前後の refname のオブジェクト名です。作成された参照は sha1-old が 0{40} に等しくなり、削除された参照は sha1-new が 0{40} に等しくなります。それ以外の場合、sha1-old と sha1-new はリポジトリ内の有効なオブジェクトである必要があります。

署名付きプッシュを受け入れた後、pre-receiveフックと同様に、GIT_PUSH_CERT*環境変数を検査できます。

このフックを使用すると、リポジトリへの更新を記述するメールを簡単に生成できます。このスクリプト例は、リポジトリにプッシュされたコミットをリストするメールを各参照ごとに送信し、良好な署名を持つ署名付きプッシュのプッシュ証明書をロガーサービスに記録します。

#!/bin/sh
# mail out commit update information.
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Created a new ref, with the following commits:"
		git rev-list --pretty "$nval"
	else
		echo "New commits:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "Changes to ref $ref" commit-list@mydomain
done
# log signed push certificate, if any
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
	(
		echo expected nonce is ${GIT_PUSH_NONCE}
		git cat-file blob ${GIT_PUSH_CERT}
	) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

このフック呼び出しからの終了コードは無視されますが、ゼロ以外の終了コードはエラーメッセージを生成します。

このフックが実行される際に、refnameにsha1-newがない可能性があることに注意してください。これは、*git-receive-pack*によって更新された後、フックがそれを評価する前に、別のユーザーがその参照を変更した場合に簡単に発生する可能性があります。フックはrefnameの現在の値ではなく、sha1-newに依存することをお勧めします。

POST-UPDATE フック

他のすべての処理の後、少なくとも1つの参照が更新され、$GIT_DIR/hooks/post-update ファイルが存在し、実行可能であれば、post-updateが更新された参照のリストとともに呼び出されます。これは、リポジトリ全体にわたるクリーンアップタスクを実装するために使用できます。

このフック呼び出しからの終了コードは無視されます。その時点で*git-receive-pack*に残された唯一のことは、とにかく自身を終了することです。

このフックは、例えば、リポジトリがパックされており、ダムトランスポートを介して提供されている場合にgit update-server-infoを実行するために使用できます。

#!/bin/sh
exec git update-server-info

隔離環境

receive-packがオブジェクトを受け取ると、それらは$GIT_DIR/objectsディレクトリ内の「隔離」一時ディレクトリに配置され、pre-receiveフックが完了した後にのみメインオブジェクトストアに移行されます。それより前にプッシュが失敗した場合、一時ディレクトリは完全に削除されます。

これにはいくつかのユーザーに影響する効果と注意点があります。

受信パックの問題、オブジェクトの欠落、またはpre-receiveフックが原因で失敗したプッシュは、ディスク上にデータを残しません。これは通常、繰り返し失敗するプッシュがディスクを占有するのを防ぐのに役立ちますが、デバッグをより困難にする可能性があります。
pre-receiveフックによって作成されたオブジェクトは、隔離ディレクトリに作成され (そして成功した場合にのみ移行されます)。
pre-receiveフックは、隔離されたオブジェクトを指すように参照を更新してはなりません。リポジトリにアクセスする他のプログラムはこれらのオブジェクトを見ることができません (そして、pre-receiveフックが失敗した場合、それらの参照は破損します)。安全のため、pre-receive内からの参照更新は自動的に拒否されます。

git[1]スイートの一部

セットアップと設定

プロジェクトの取得と作成

基本的なスナップショット作成

ブランチとマージ

プロジェクトの共有と更新

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

配管コマンド

名前

概要

説明