英語フランス語スペイン語

Ad


OnWorksファビコン

git-receive-pack - クラウドでオンライン

Ubuntu Online、Fedora Online、Windows オンライン エミュレーター、または MAC OS オンライン エミュレーターを介して OnWorks 無料ホスティング プロバイダーで git-receive-pack を実行します。

これは、Ubuntu Online、Fedora Online、Windows オンライン エミュレーター、MAC OS オンライン エミュレーターなどの複数の無料オンライン ワークステーションの 1 つを使用して、OnWorks 無料ホスティング プロバイダーで実行できるコマンド git-receive-pack です。

プログラム:

NAME


git-receive-pack - リポジトリにプッシュされたものを受信します

SYNOPSIS


git 受信パック

DESCRIPTION


呼び出し元 git 送信パック そして、から供給された情報でリポジトリを更新します。
リモートエンド。

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

このコマンドにより、sha1 ref (ヘッド/タグ) の作成と高速転送が可能になります。
リモートエンド(厳密にはローカルエンド) git 受信パック 実行されますが、ユーザーに対して
送信パック側に座っている人は、リモートを更新しています。混乱した?)

更新フックと更新後フックを使用する実際の例は他にもあります。
ドキュメント/ハウツー ディレクトリ。

git 受信パック accept.denyNonFastForwards 設定オプションを尊重します。
早送りでない場合、ref への更新は拒否されるべきです。

OPTIONS



同期先のリポジトリ。

事前受信 HOOK


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

sha1-古いSP sha1-新しいSP refname LF

refname 値は $GIT_DIR に対する相対値です。例えばマスターヘッドの場合はこれです
「リファレンス/ヘッド/マスター」。各 refname の前にある 1 つの shaXNUMX 値は、
更新前と更新後の refname。作成される Ref の sha1-old は 0{40} になります。
一方、削除される参照の sha1-new は 0{40} に等しく、それ以外の場合は sha1-old と
sha1-new はリポジトリ内の有効なオブジェクトである必要があります。

署名付きプッシュを受け入れるとき (「 git-プッシュ(1))、署名されたプッシュ証明書は次の場所に保存されます。
blob と環境変数 GIT_PUSH_CERT でそのオブジェクト名を調べることができます。見る
例として、受信後フックの説明を参照してください。なお、証明書は、
GPG を使用して検証され、結果は次の環境変数を使用してエクスポートされます。

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

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

GIT_PUSH_CERT_STATUS
と同じニーモニックを使用した、プッシュ証明書の GPG 検証のステータス。
%G で使用されますか?コマンドの git log ファミリの形式 (「 git-ログ(1))。

GIT_PUSH_CERT_NONCE
プロセスが署名者にプッシュ証明書に含めるよう要求したノンス文字列。もし
これは、プッシュ証明書の「nonce」ヘッダーに記録されている値と一致しません。
これは、証明書が有効な証明書であり、
別の「git Push」セッション。

GIT_PUSH_CERT_NONCE_STATUS

未承諾
「git Push --signed」は、送信を要求していないのに nonce を送信しました。

欠落
「git Push --signed」は nonce ヘッダーを送信しませんでした。

BAD
「git Push --signed」は偽の nonce を送信しました。

OK
「git Push --signed」は、送信を要求した nonce を送信しました。

スロップ
「git Push --signed」は、現在送信するように要求したものとは異なる nonce を送信しましたが、
前のセッションで。 GIT_PUSH_CERT_NONCE_SLOP 環境変数を参照してください。

GIT_PUSH_CERT_NONCE_SLOP
「git Push --signed」は、現在送信するように要求したものとは異なるノンスを送信しましたが、
開始時間がこの秒数異なる別のセッション
現在のセッション。 GIT_PUSH_CERT_NONCE_STATUS が SLOP を示している場合にのみ意味があります。こちらもお読みください
の accept.certNonceSlop 変数について git-configとします。

このフックは、refname が更新される前、および早送りチェックが行われる前に呼び出されます。
実行されました。

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

UPDATE HOOK


各参照が更新される前に、$GIT_DIR/hooks/update ファイルが存在し、実行可能であれば、
3 つのパラメータを使用して、参照ごとに 1 回呼び出されます。

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

refname パラメータは $GIT_DIR に対する相対値です。例えばマスターヘッドの場合はこれです
「リファレンス/ヘッド/マスター」。 1 つの shaXNUMX 引数は、前の refname のオブジェクト名です。
そしてアップデート後。フックは refname が更新される前に呼び出されることに注意してください。
sha1-old が 0{40} (そのような参照がまだ存在しないことを意味します) であるか、それと一致する必要があります。
refnameに記録されます。

名前付き参照の更新を禁止したい場合、フックはゼロ以外のステータスで終了する必要があります。
それ以外の場合は、ゼロで終了する必要があります。

このフックの実行が成功しても (終了ステータスがゼロ)、ref が確実に実行されるわけではありません。
実際に更新されることは前提条件にすぎません。したがって、送信するのは得策ではありません
このフックからの通知 (電子メールなど)。代わりに post-receive フックの使用を検討してください。

受信後 HOOK


すべての参照が更新された (または更新が試みられた) 後、いずれかの参照の更新があった場合、
成功し、$GIT_DIR/hooks/post-receive ファイルが存在し、実行可能であれば、
パラメーターなしで 1 回呼び出されます。フックの標準入力はそれぞれ 1 行になります。
参照が正常に更新されました:

sha1-古いSP sha1-新しいSP refname LF

refname 値は $GIT_DIR に対する相対値です。例えばマスターヘッドの場合はこれです
「リファレンス/ヘッド/マスター」。各 refname の前にある 1 つの shaXNUMX 値は、
更新前と更新後の refname。作成された Ref の sha1-old は次のようになります。
0{40}。削除された参照の sha1-new は 0{40} に等しくなります。それ以外の場合は sha1-old になります。
および sha1-new はリポジトリ内の有効なオブジェクトである必要があります。

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

このフックを使用すると、リポジトリの更新を説明するメールを簡単に生成できます。
このサンプル スクリプトは、参照ごとに 1 つのメール メッセージを送信し、プッシュされたコミットをリストします。
リポジトリに保存し、適切な署名を持つ署名付きプッシュのプッシュ証明書を
ロガーサービス:

#!/bin/sh
# コミット更新情報をメール送信します。
読み取り中、oval nval ref
do
if expr "$oval" : '0*$' >/dev/null
その後
echo "次のコミットを含む新しい参照を作成しました:"
git rev-list --pretty "$nval"
ほかに
echo "新しいコミット:"
git rev-list --pretty "$nval" "^$oval"
フィ |
mail -s "ref $ref への変更" commit-list@mydomain
行われ
# 署名付きプッシュ証明書があればログに記録します
if テスト -n "${GIT_PUSH_CERT-}" && テスト ${GIT_PUSH_CERT_STATUS} = G
その後
(
エコーで期待されるナンスは ${GIT_PUSH_NONCE} です
git cat-file blob ${GIT_PUSH_CERT}
) | mail -s "$GIT_PUSH_CERT_SIGNER から証明書をプッシュ" Push-log@mydomain
fi
0番出口

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

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

アップデート後 HOOK


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

このフック呼び出しからの終了コードは無視されます。残された唯一のもの
git 受信パック その時点で行うべきことは、とにかくそれ自体を終了することです。

このフックは、たとえばリポジトリが次の場合に git update-server-info を実行するために使用できます。
梱包され、ダムトランスポート経由で提供されます。

#!/bin/sh
git 更新サーバー情報を実行する

onworks.net サービスを使用してオンラインで git-receive-pack を使用する


無料のサーバーとワークステーション

Windows と Linux のアプリをダウンロード

Linuxコマンド

Ad