Git

git-receive-pack は 2.50.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 を参照してください。
--skip-connectivity-check: 到達可能なオブジェクトの推移閉包内のすべてのオブジェクトの存在を検証する接続性チェックをバイパスします。このオプションは、Gitの外部で独自のオブジェクト接続性検証を実装したいサーバーオペレーターを対象としています。これは、サーバー側がGitの使用方法に関する追加情報を知っており、Git自体ではできないオブジェクト接続性をより効率的に計算するための特定の保証に頼ることができる場合に役立ちます。信頼できる外部メカニズムなしでこのオプションを使用すると、リポジトリが破損するリスクがあり、一般的なケースでは使用すべきではありません。

PRE-RECEIVE フック

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

sha1-old SP sha1-new SP refname LF

refname の値は $GIT_DIR に対する相対パスです。例えば、masterヘッドの場合は "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

git log ファミリコマンドの %G? 形式で使用されるのと同じニーモニックを使用して、プッシュ証明書のGPG検証のステータス (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 変数についても読んでください。

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

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ヘッドの場合は "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ヘッドの場合は "refs/heads/master" です。各refnameの前にある2つのsha1値は、更新前と更新後のrefnameのオブジェクト名です。作成された参照は sha1-old が 0{40} になります。削除された参照は sha1-new が 0{40} になります。それ以外の場合、sha1-old と sha1-new はリポジトリ内の有効なオブジェクトである必要があります。

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

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

#!/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*によって更新された後、フックがそれを評価する前に、別のユーザーがrefを変更した場合に簡単に発生します。フックは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]スイートの一部

セットアップと設定

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

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

ブランチとマージ

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

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

配管コマンド

名前

概要

説明