日本語 ▾ トピック ▾ 最新バージョン ▾ githooks は2.46.1で最終更新されました

名称

githooks - Gitが使用するフック

書式

$GIT_DIR/hooks/* (または `git config core.hooksPath`/*)

説明

フックは、Gitの実行中の特定の時点でアクションをトリガーするために、hooksディレクトリに配置できるプログラムです。実行可能ビットが設定されていないフックは無視されます。

デフォルトでは、hooksディレクトリは$GIT_DIR/hooksですが、core.hooksPath設定変数(git-config[1]を参照)によって変更できます。

Gitはフックを呼び出す前に、作業ディレクトリをベアリポジトリの場合は$GIT_DIR、非ベアリポジトリの場合は作業ツリーのルートに変更します。プッシュ中にトリガーされるフック(pre-receiveupdatepost-receivepost-updatepush-to-checkout)は例外で、これらは常に$GIT_DIRで実行されます。

GIT_DIRGIT_WORK_TREEなどの環境変数は、フックによって実行されるGitコマンドがリポジトリを正しく特定できるようにエクスポートされます。フックが外部リポジトリまたは同じリポジトリの異なる作業ツリーでGitコマンドを呼び出す必要がある場合は、これらの環境変数をクリアして、外部の場所でのGit操作に干渉しないようにする必要があります。例えば

local_desc=$(git describe)
foreign_desc=$(unset $(git rev-parse --local-env-vars); git -C ../foreign-repo describe)

フックは、環境変数、コマンドライン引数、および標準入力から引数を受け取ることができます。詳細については、以下の各フックのドキュメントを参照してください。

git initは、設定に応じて、新しいリポジトリにフックをコピーする場合があります。git-init[1]の「TEMPLATE DIRECTORY」セクションを参照してください。このドキュメントの残りの部分で「デフォルトのフック」という場合は、Gitに同梱されているデフォルトのテンプレートについて言及しています。

現在サポートされているフックについては、以下で説明します。

フック

applypatch-msg

このフックはgit-am[1]によって呼び出されます。これは単一のパラメータを受け取り、提案されたコミットログメッセージを保持するファイルの名前です。ゼロ以外のステータスで終了すると、git amはパッチを適用する前に中止されます。

このフックは、メッセージファイルをその場で編集することができ、メッセージをプロジェクトの標準形式に正規化するために使用できます。また、メッセージファイルを検査した後でコミットを拒否するためにも使用できます。

デフォルトのapplypatch-msgフックは、有効になっている場合、commit-msgフックが有効であれば、それを実行します。

pre-applypatch

このフックはgit-am[1]によって呼び出されます。パラメータは取らず、パッチが適用された後、コミットが作成される前に呼び出されます。

ゼロ以外のステータスで終了した場合、パッチ適用後に作業ツリーはコミットされません。

現在の作業ツリーを検査し、特定のテストに合格しない場合にコミットを拒否するために使用できます。

デフォルトのpre-applypatchフックは、有効になっている場合、pre-commitフックが有効であれば、それを実行します。

post-applypatch

このフックはgit-am[1]によって呼び出されます。パラメータは取らず、パッチが適用されてコミットが作成された後に呼び出されます。

このフックは主に通知を目的としており、git amの結果には影響を与えません。

pre-commit

このフックはgit-commit[1]によって呼び出され、--no-verifyオプションでバイパスできます。パラメータは取らず、提案されたコミットログメッセージを取得し、コミットを作成する前に呼び出されます。このスクリプトからゼロ以外のステータスで終了すると、git commitコマンドはコミット作成前に中止されます。

デフォルトのpre-commitフックは、有効になっている場合、末尾に空白文字を含む行の導入を検出し、そのような行が見つかった場合にコミットを中止します。

コマンドがコミットメッセージを変更するためのエディタを起動しない場合、すべてのgit commitフックは環境変数GIT_EDITOR=:が設定された状態で呼び出されます。

デフォルトのpre-commitフックは、有効になっている場合、およびhooks.allownonascii設定オプションが未設定またはfalseに設定されている場合、非ASCIIファイル名の使用を防ぎます。

pre-merge-commit

このフックはgit-merge[1]によって呼び出され、--no-verifyオプションでバイパスできます。パラメータは取らず、マージが正常に実行された後、コミットログメッセージを取得してコミットを作成する前に呼び出されます。このスクリプトからゼロ以外のステータスで終了すると、git mergeコマンドはコミット作成前に中止されます。

デフォルトのpre-merge-commitフックは、有効になっている場合、pre-commitフックが有効であれば、それを実行します。

コマンドがコミットメッセージを変更するためのエディタを起動しない場合、このフックは環境変数GIT_EDITOR=:が設定された状態で呼び出されます。

マージを自動的に実行できない場合、競合を解決し、結果を別途コミットする必要があります(git-merge[1]を参照)。その時点では、このフックは実行されませんが、pre-commitフックが有効であれば実行されます。

prepare-commit-msg

このフックはgit-commit[1]によって、デフォルトのログメッセージを準備した直後、エディタが起動する前に呼び出されます。

これは1から3つのパラメータを受け取ります。最初のパラメータは、コミットログメッセージを含むファイルの名前です。2番目のパラメータはコミットメッセージのソースであり、次のいずれかになります: message-mまたは-Fオプションが指定された場合)、template-tオプションが指定された場合、または設定オプションcommit.templateが設定されている場合)、merge(コミットがマージであるか、.git/MERGE_MSGファイルが存在する場合)、squash.git/SQUASH_MSGファイルが存在する場合)、またはcommitの後にコミットオブジェクト名(-c-Cまたは--amendオプションが指定された場合)が続きます。

終了ステータスがゼロ以外の場合、git commitは中止されます。

このフックの目的は、メッセージファイルをその場で編集することであり、--no-verifyオプションによって抑制されません。ゼロ以外の終了は、フックの失敗を意味し、コミットを中止します。これはpre-commitフックの代替として使用すべきではありません。

Gitに付属しているサンプルprepare-commit-msgフックは、コミットテンプレートのコメント部分にあるヘルプメッセージを削除します。

commit-msg

このフックはgit-commit[1]およびgit-merge[1]によって呼び出され、--no-verifyオプションでバイパスできます。これは単一のパラメータを受け取り、提案されたコミットログメッセージを保持するファイルの名前です。ゼロ以外のステータスで終了すると、コマンドは中止されます。

このフックは、メッセージファイルをその場で編集することができ、メッセージをプロジェクトの標準形式に正規化するために使用できます。また、メッセージファイルを検査した後でコミットを拒否するためにも使用できます。

デフォルトのcommit-msgフックは、有効になっている場合、重複するSigned-off-byトレーラーを検出し、それが発見された場合にコミットを中止します。

post-commit

このフックはgit-commit[1]によって呼び出されます。パラメータは取らず、コミットが作成された後に呼び出されます。

このフックは主に通知を目的としており、git commitの結果には影響を与えません。

pre-rebase

このフックはgit-rebase[1]によって呼び出され、ブランチがリベースされるのを防ぐために使用できます。このフックは1つまたは2つのパラメータで呼び出される場合があります。最初のパラメータは、シリーズが分岐した上流です。2番目のパラメータはリベースされるブランチであり、現在のブランチをリベースする場合は設定されません。

post-checkout

このフックは、作業ツリーを更新した後でgit-checkout[1]またはgit-switch[1]が実行されたときに呼び出されます。このフックには3つのパラメータが与えられます: 以前のHEADのリファレンス、新しいHEADのリファレンス(変更されたかどうかにかかわらず)、およびチェックアウトがブランチチェックアウト(ブランチの変更、flag=1)であったかファイルチェックアウト(インデックスからファイルを取得、flag=0)であったかを示すフラグです。このフックは、フックの終了ステータスがこれら2つのコマンドの終了ステータスになること以外は、git switchまたはgit checkoutの結果に影響を与えません。

また、--no-checkout-n)オプションが使用されていない限り、git-clone[1]の後にも実行されます。フックに与えられる最初のパラメータはnull-ref、2番目は新しいHEADのリファレンスで、フラグは常に1です。git worktree addについても同様で、--no-checkoutが使用されていない限り同じです。

このフックは、リポジトリの有効性チェックの実行、以前のHEADとの差分が異なる場合の自動表示、または作業ディレクトリのメタデータプロパティの設定に使用できます。

post-merge

このフックはgit-merge[1]によって呼び出されます。これは、ローカルリポジトリでgit pullが実行されたときに発生します。このフックは単一のパラメータを受け取り、実行されたマージがスカッシュマージであったかどうかを指定するステータスフラグです。このフックはgit mergeの結果に影響を与えず、競合によりマージが失敗した場合は実行されません。

このフックは、対応するpre-commitフックと組み合わせて、作業ツリーに関連付けられたあらゆる形式のメタデータ(例:パーミッション/所有権、ACLSなど)を保存および復元するために使用できます。これを行う方法の例については、contrib/hooks/setgitperms.perlを参照してください。

pre-push

このフックはgit-push[1]によって呼び出され、プッシュが実行されるのを防ぐために使用できます。このフックは、宛先リモートの名前と場所を提供する2つのパラメータとともに呼び出されます。名前付きリモートが使用されていない場合、両方の値は同じになります。

プッシュされるものに関する情報は、フックの標準入力に次の形式の行で提供されます

<local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF

例えば、git push origin master:foreignコマンドが実行された場合、フックは次のような行を受け取ります

refs/heads/master 67890 refs/heads/foreign 12345

ただし、完全なオブジェクト名が提供されます。外部リファレンスがまだ存在しない場合、<remote-object-name>はすべてゼロのオブジェクト名になります。リファレンスが削除される場合、<local-ref>(delete)として提供され、<local-object-name>はすべてゼロのオブジェクト名になります。ローカルコミットが展開可能な名前(HEAD~やオブジェクト名など)以外のもので指定された場合、それは元々与えられたとおりに提供されます。

このフックがゼロ以外のステータスで終了した場合、git pushは何もプッシュせずに中止されます。プッシュが拒否された理由に関する情報は、標準エラーに出力することでユーザーに送信できます。

pre-receive

このフックはgit-receive-pack[1]によって、git pushに応答してリポジトリ内のリファレンスを更新するときに呼び出されます。リモートリポジトリのリファレンスを更新し始める直前に、pre-receiveフックが呼び出されます。その終了ステータスは更新の成功または失敗を決定します。

このフックは受信操作ごとに1回実行されます。引数は取らず、更新される各リファレンスに対して標準入力から以下の形式の行を受け取ります

<old-oid> SP <new-oid> SP <ref-name> LF

ここで、<old-oid>はリファレンスに格納されていた古いオブジェクト名、<new-oid>はリファレンスに格納される新しいオブジェクト名、<ref-name>はリファレンスのフルネームです。新しいリファレンスを作成する場合、<old-oid>はすべてゼロのオブジェクト名になります。

フックがゼロ以外のステータスで終了した場合、どのリファレンスも更新されません。フックがゼロで終了した場合でも、個々のリファレンスの更新はupdateフックによって引き続き防ぐことができます。

標準出力と標準エラー出力はどちらも、相手側のgit send-packに転送されるため、ユーザーにメッセージをechoするだけで済みます。

git push --push-option=...のコマンドラインで与えられたプッシュオプションの数は、環境変数GIT_PUSH_OPTION_COUNTから読み取ることができ、オプション自体はGIT_PUSH_OPTION_0GIT_PUSH_OPTION_1、...にあります。プッシュオプションフェーズを使用しないよう交渉された場合、環境変数は設定されません。クライアントがプッシュオプションの使用を選択したが、何も送信しなかった場合、カウント変数はゼロ、GIT_PUSH_OPTION_COUNT=0に設定されます。

いくつかの注意点については、git-receive-pack[1]の「Quarantine Environment」セクションを参照してください。

update

このフックはgit-receive-pack[1]によって、git pushに応答してリポジトリ内のリファレンスを更新するときに呼び出されます。リモートリポジトリのリファレンスを更新する直前に、updateフックが呼び出されます。その終了ステータスはリファレンス更新の成功または失敗を決定します。

このフックは、更新される各リファレンスに対して1回実行され、3つのパラメータを取ります

  • 更新されるリファレンスの名前、

  • リファレンスに格納されていた古いオブジェクト名、

  • そして、リファレンスに格納される新しいオブジェクト名です。

updateフックがゼロで終了すると、リファレンスの更新が許可されます。ゼロ以外のステータスで終了すると、git receive-packがそのリファレンスを更新するのを防ぎます。

このフックは、オブジェクト名が古いオブジェクト名で指定されたコミットオブジェクトの子孫であるコミットオブジェクトであることを確認することで、特定の参照に対する強制更新を防ぐために使用できます。つまり、「ファストフォワードのみ」ポリシーを強制するためです。

また、old..newの状態をログに記録するためにも使用できます。ただし、ブランチの完全なセットを知らないため、素朴に使用するとリファレンスごとに1通のメールが送信されることになります。post-receiveフックの方がこれに適しています。

ワイヤ経由でGitコマンドへのアクセスのみを制限する環境では、このフックを使用して、ファイルシステムの所有権とグループメンバーシップに依存せずにアクセス制御を実装できます。ユーザーのGitコマンドへのアクセスを制限するためにログインシェルをどのように使用できるかについては、git-shell[1]を参照してください。

標準出力と標準エラー出力はどちらも、相手側のgit send-packに転送されるため、ユーザーにメッセージをechoするだけで済みます。

デフォルトのupdateフックは、有効になっている場合、およびhooks.allowunannotated設定オプションが未設定またはfalseに設定されている場合、アノテーションなしのタグがプッシュされるのを防ぎます。

proc-receive

このフックはgit-receive-pack[1]によって呼び出されます。サーバーが複数値の設定変数receive.procReceiveRefsを設定しており、receive-packに送信されたコマンドに一致するリファレンス名がある場合、これらのコマンドは内部のexecute_commands()関数ではなく、このフックによって実行されます。このフックは、関連するリファレンスを更新し、結果をreceive-packに報告する責任があります。

このフックは受信操作ごとに1回実行されます。引数は取らず、pkt-line形式のプロトコルを使用してreceive-packと通信し、コマンド、プッシュオプションを読み取り、結果を送信します。以下のプロトコルの例では、文字Sreceive-packを表し、文字Hはこのフックを表します。

# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive results from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference.  The alternate reference name
# and other status can be given in option directives.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt

proc-receiveフックの各コマンドは擬似リファレンスを指すことができ、常にzero-oldをold-oidとして持ちますが、proc-receiveフックは代替リファレンスを更新することができ、代替リファレンスは既にゼロ以外のold-oidで存在する場合があります。この場合、このフックは「option」ディレクティブを使用して、先行する「ok」ディレクティブで与えられたリファレンスの拡張属性を報告します。

このフックのコマンドのレポートは、入力と同じ順序である必要があります。proc-receiveフックの終了ステータスは、アトミックプッシュが使用されていない限り、それに送信されたコマンドのグループの成功または失敗のみを決定します。

post-receive

このフックはgit-receive-pack[1]によって、git pushに応答してリポジトリ内のリファレンスを更新するときに呼び出されます。このフックは、提案されたすべてのリファレンス更新が処理され、その結果少なくとも1つのリファレンスが更新された後に、リモートリポジトリで1回実行されます。

このフックは引数を取りません。pre-receiveフックと同じ形式で、正常に更新された各リファレンスについて標準入力から1行を受け取ります。

このフックは、実際の作業が完了した後に呼び出されるため、git receive-packの結果には影響を与えません。

これはpost-updateフックを置き換えるもので、リファレンスの名前だけでなく、すべてのリファレンスの古い値と新しい値の両方を取得します。

標準出力と標準エラー出力はどちらも、相手側のgit send-packに転送されるため、ユーザーにメッセージをechoするだけで済みます。

デフォルトのpost-receiveフックは空ですが、Gitディストリビューションのcontrib/hooksディレクトリに、コミットメールの送信を実装するサンプルスクリプトpost-receive-emailが提供されています。

git push --push-option=...のコマンドラインで与えられたプッシュオプションの数は、環境変数GIT_PUSH_OPTION_COUNTから読み取ることができ、オプション自体はGIT_PUSH_OPTION_0GIT_PUSH_OPTION_1、...にあります。プッシュオプションフェーズを使用しないよう交渉された場合、環境変数は設定されません。クライアントがプッシュオプションの使用を選択したが、何も送信しなかった場合、カウント変数はゼロ、GIT_PUSH_OPTION_COUNT=0に設定されます。

詳細については、git-receive-pack[1]の「post-receive」セクションを参照してください。

post-update

このフックはgit-receive-pack[1]によって、git pushに応答してリポジトリ内のリファレンスを更新するときに呼び出されます。すべてのリファレンスが更新された後、リモートリポジトリで1回実行されます。

これは可変数のパラメータを受け取り、それぞれが実際に更新されたリファレンスの名前です。

このフックは主に通知を目的としており、git receive-packの結果には影響を与えません。

post-updateフックはプッシュされたヘッドが何かを伝えることはできますが、その元の値と更新された値を知らないため、old..newをログに記録するには不適切な場所です。post-receiveフックはリファレンスの元の値と更新された値の両方を取得します。それらが必要な場合は、代わりにそちらを検討してもよいでしょう。

有効になっている場合、デフォルトのpost-updateフックはgit update-server-infoを実行して、ダムトランスポート(例:HTTP)で使用される情報を最新に保ちます。HTTP経由でアクセス可能なGitリポジトリを公開している場合は、このフックを有効にすることをお勧めします。

標準出力と標準エラー出力はどちらも、相手側のgit send-packに転送されるため、ユーザーにメッセージをechoするだけで済みます。

reference-transaction

このフックは、リファレンス更新を実行するすべてのGitコマンドによって呼び出されます。リファレンストランザクションが準備、コミット、または中止されるたびに実行され、したがって複数回呼び出される場合があります。このフックはシンボリックリファレンスの更新もサポートしています。

このフックは厳密に1つの引数を取ります。これは、指定されたリファレンストランザクションの現在の状態です

  • 「prepared」(準備済み):すべてのリファレンス更新がトランザクションにキューイングされ、リファレンスがディスク上でロックされました。

  • 「committed」(コミット済み):リファレンストランザクションがコミットされ、すべてのリファレンスがそれぞれの新しい値を持つようになりました。

  • 「aborted」(中止済み):リファレンストランザクションが中止され、変更は行われず、ロックが解放されました。

トランザクションに追加された各リファレンス更新について、フックは標準入力から以下の形式の行を受け取ります

<old-value> SP <new-value> SP <ref-name> LF

ここで、<old-value>はリファレンストランザクションに渡された古いオブジェクト名、<new-value>はリファレンスに格納される新しいオブジェクト名、<ref-name>はリファレンスのフルネームです。現在の値にかかわらずリファレンスを強制的に更新する場合、またはリファレンスを新たに作成する場合、<old-value>はすべてゼロのオブジェクト名になります。これらのケースを区別するには、git rev-parseを介して<ref-name>の現在の値を検査できます。

シンボリックリファレンスの更新の場合、<old_value>および<new-value>フィールドはオブジェクトではなくリファレンスを示すことがあります。リファレンスはref:<ref-target>のようにref:プレフィックスで示されます。

フックの終了ステータスは、「prepared」状態以外のすべての状態では無視されます。「prepared」状態では、ゼロ以外の終了ステータスはトランザクションの中止を引き起こします。その場合、フックは「aborted」状態で呼び出されません。

push-to-checkout

このフックはgit-receive-pack[1]によって、git pushに応答してリポジトリ内のリファレンスを更新するとき、およびプッシュが現在チェックアウトされているブランチを更新しようとし、receive.denyCurrentBranch設定変数がupdateInsteadに設定されている場合に呼び出されます。このようなプッシュは、デフォルトではリモートリポジトリの作業ツリーとインデックスが現在チェックアウトされているコミットと異なる場合、拒否されます。作業ツリーとインデックスの両方が現在のコミットと一致する場合、それらは新しくプッシュされたブランチの先端と一致するように更新されます。このフックは、デフォルトの動作を上書きするために使用されます。

このフックは、現在のブランチの先端が更新されるコミットを受け取ります。ゼロ以外のステータスで終了してプッシュを拒否することができます(その場合、インデックスや作業ツリーを変更してはなりません)。または、現在のブランチの先端が新しいコミットに更新されたときに、作業ツリーとインデックスを目的の状態にするために必要な変更を行い、ゼロステータスで終了することができます。

例えば、このフックはgit read-tree -u -m HEAD "$1"を単純に実行することで、git pushで逆方向に実行されるgit fetchをエミュレートできます。なぜなら、git read-tree -u -mの2ツリー形式は、ブランチ間の差分に干渉しないローカル変更を作業ツリーに残しながらブランチを切り替えるgit switchgit checkoutと本質的に同じだからです。

pre-auto-gc

このフックはgit gc --autogit-gc[1]を参照)によって呼び出されます。パラメータは取らず、このスクリプトからゼロ以外のステータスで終了すると、git gc --autoは中止されます。

post-rewrite

このフックは、コミットを書き換えるコマンド(--amend付きで呼び出された場合のgit-commit[1]、およびgit-rebase[1])によって呼び出されます(ただし、git-fast-import[1]git-filter-repoのような完全な履歴を書き換えるツールは通常これを呼び出しません!)。その最初の引数は、呼び出し元のコマンドを示します。現在はamendまたはrebaseのいずれかです。将来、さらにコマンドに依存する引数が渡される可能性があります。

このフックは、標準入力で書き換えられたコミットのリストを次の形式で受け取ります

<old-object-name> SP <new-object-name> [ SP <extra-info> ] LF

extra-infoは、ここでもコマンドに依存します。空の場合、先行するSPも省略されます。現在、どのコマンドもextra-infoを渡していません。

このフックは、自動ノートコピー(git-config[1]の「notes.rewrite.<command>」を参照)が行われた後に常に実行され、したがってこれらのノートにアクセスできます。

以下のコマンド固有のコメントが適用されます

rebase

squashおよびfixup操作の場合、スカッシュされたすべてのコミットは、スカッシュされたコミットに書き換えられたものとしてリストされます。これは、同じnew-object-nameを共有する複数の行が存在することを意味します。

コミットは、rebaseによって処理された順序でリストされることが保証されています。

sendemail-validate

このフックはgit-send-email[1]によって呼び出されます。

これは以下のコマンドライン引数を取ります。それらは、1. 送信するメールの内容を保持するファイルの名前。2. メールのSMTPヘッダーを保持するファイルの名前です。

SMTPヘッダーは、ユーザーのメール転送エージェント(MTA)に渡されるのとまったく同じ方法で渡されます。実質的に、ユーザーのMTAに与えられるメールは、$2の内容の後に$1の内容が続いたものです。

いくつかの一般的なヘッダーの例を以下に示します。大文字小文字の区別と複数行のタブ構造に注意してください。

From: Example <from@example.com>
To: to@example.com
Cc: cc@example.com,
 A <author@example.com>,
 One <one@example.com>,
 two@example.com
Subject: PATCH-STRING

ゼロ以外のステータスで終了すると、git send-emailはいずれのメールも送信する前に中止されます。

フック実行時に以下の環境変数が設定されます。

GIT_SENDEMAIL_FILE_COUNTER

送信されるメールを保持する各ファイル(FIFOを除く)ごとに1つずつ増加する1ベースのカウンターです。このカウンターはパッチシリーズのカウンター方式には従いません。常に1から始まり、GIT_SENDEMAIL_FILE_TOTALで終了します。

GIT_SENDEMAIL_FILE_TOTAL

送信されるファイルの総数(FIFOを除く)です。このカウンターはパッチシリーズのカウンター方式には従いません。カバーレターがあるかどうかにかかわらず、常に送信されるファイルの数に等しくなります。

これらの変数は、例えばパッチシリーズの検証に使用できます。

Gitに付属しているサンプルsendemail-validateフックは、送信されたすべてのパッチ(カバーレターを除く)が、競合なしで上流リポジトリのデフォルトブランチに適用できることを確認します。特定のシリーズのすべてのパッチが適用された後に行う追加の検証ステップのために、いくつかのプレースホルダーが残されています。

fsmonitor-watchman

このフックは、使用するフックのバージョンに応じて、設定オプションcore.fsmonitor.git/hooks/fsmonitor-watchmanまたは.git/hooks/fsmonitor-watchmanv2に設定されている場合に呼び出されます。

バージョン1は2つの引数を取ります。バージョン(1)と、1970年1月1日深夜からの経過ナノ秒時間です。

バージョン2は2つの引数を取ります。バージョン(2)と、トークン以降の変更を識別するために使用されるトークンです。watchmanの場合、これはクロックIDになります。このバージョンは、ファイルリストの前に新しいトークンとそれに続くNULを標準出力に出力する必要があります。

このフックは、要求された時間以降に変更された可能性のある作業ディレクトリ内のすべてのファイルのリストを標準出力に出力する必要があります。潜在的な変更を見逃さないように、ロジックは包括的である必要があります。パスは作業ディレクトリのルートからの相対パスであり、単一のNULで区切られている必要があります。

実際に変更されていないファイルを含めても問題ありません。新しく作成されたファイルや削除されたファイルを含むすべての変更を含める必要があります。ファイルの名前が変更された場合、古い名前と新しい名前の両方を含める必要があります。

Gitは、与えられたパス名に基づいて、変更をチェックするファイルと、追跡されていないファイルをチェックするディレクトリを制限します。

Gitに「すべてのファイルが変更された」と伝える最適化された方法は、ファイル名/を返すことです。

終了ステータスは、Gitがフックからのデータを使用して検索を制限するかどうかを決定します。エラーが発生した場合、すべてのファイルとフォルダの検証にフォールバックします。

p4-changelist

このフックはgit-p4 submitによって呼び出されます。

p4-changelistフックは、チェンジリストメッセージがユーザーによって編集された後に実行されます。--no-verifyオプションでバイパスできます。これは単一のパラメータを受け取り、提案されたチェンジリストテキストを保持するファイルの名前です。ゼロ以外のステータスで終了すると、コマンドは中止されます。

このフックはチェンジリストファイルを編集することができ、テキストをプロジェクトの標準形式に正規化するために使用できます。また、メッセージファイルを検査した後でコミット(Submit)を拒否するためにも使用できます。

詳細については、git-p4 submit --helpを実行してください。

p4-prepare-changelist

このフックはgit-p4 submitによって呼び出されます。

p4-prepare-changelistフックは、デフォルトのチェンジリストメッセージを準備した直後、エディタが起動する前に実行されます。これは1つのパラメータを受け取り、チェンジリストテキストを含むファイルの名前です。このスクリプトからゼロ以外のステータスで終了すると、プロセスは中止されます。

このフックの目的は、メッセージファイルをその場で編集することであり、--no-verifyオプションによって抑制されません。このフックは--prepare-p4-onlyが設定されている場合でも呼び出されます。

詳細については、git-p4 submit --helpを実行してください。

p4-post-changelist

このフックはgit-p4 submitによって呼び出されます。

p4-post-changelistフックは、P4でサブミットが正常に発生した後に呼び出されます。パラメータは取らず、主に通知を目的としており、git p4 submitアクションの結果には影響を与えません。

詳細については、git-p4 submit --helpを実行してください。

p4-pre-submit

このフックはgit-p4 submitによって呼び出されます。パラメータは取らず、標準入力から何も受け取りません。このスクリプトからゼロ以外のステータスで終了すると、git-p4 submitの起動が阻止されます。--no-verifyコマンドラインオプションでバイパスできます。詳細については、git-p4 submit --helpを実行してください。

post-index-change

このフックは、read-cache.cのdo_write_locked_indexでインデックスが書き込まれるときに呼び出されます。

フックに渡される最初のパラメータは、作業ディレクトリが更新されたかどうかを示すインジケータです。「1」は作業ディレクトリが更新されたことを意味し、「0」は作業ディレクトリが更新されなかったことを意味します。

フックに渡される2番目のパラメータは、インデックスが更新されたかどうか、およびskip-worktreeビットが変更された可能性があったかどうかを示すインジケータです。「1」はskip-worktreeビットが更新された可能性があったことを意味し、「0」は更新されなかったことを意味します。

フック実行時には、パラメータのいずれか1つのみが「1」に設定されるべきです。フックが「1」、「1」を渡して実行されることはありえません。

関連項目

Git

git[1]スイートの一部

scroll-to-top