githooks

NAME

githooks - Hooks used by Gitgithooks - Gitによって使用されるフック

SYNOPSIS概要

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

DESCRIPTION説明

Hooks are programs you can place in a hooks directory to trigger actions at certain points in git’s execution. Hooks that don’t have the executable bit set are ignored.フックは、gitの実行のある時点でアクションを引き起こすためにhooksディレクトリに置くことができるプログラムです。実行可能ビットが設定されていないフックは無視されます。

By default the hooks directory is $GIT_DIR/hooks, but that can be changed via the core.hooksPath configuration variable (see git-config[1]).デフォルトではhooksディレクトリはですが$GIT_DIR/hooks、それはcore.hooksPath設定変数を通して変更することができます(git-config [1]を見てください)。

Before Git invokes a hook, it changes its working directory to either $GIT_DIR in a bare repository or the root of the working tree in a non-bare repository. An exception are hooks triggered during a push (pre-receive, update, post-receive, post-update, push-to-checkout) which are always executed in $GIT_DIR.Gitはフックを呼び出す前に、作業ディレクトリをベアリポジトリの$ GIT_DIRまたは非ベアリポジトリの作業ツリーのルートに変更します。例外は、プッシュ時にトリガフック(ある前受け更新ポスト受け更新後プッシュツーチェックアウトは常に$ GIT_DIRで実行されています)。

Hooks can get their arguments via the environment, command-line arguments, and stdin. See the documentation for each hook below for details.フックは、環境、コマンドライン引数、および標準入力から引数を取得できます。詳細は下記の各フックのドキュメントを参照してください。

git init may copy hooks to the new repository, depending on its configuration. See the "TEMPLATE DIRECTORY" section in git-init[1] for details. When the rest of this document refers to "default hooks" it’s talking about the default template shipped with Git.git init設定によっては、新しいリポジトリにフックをコピーするかもしれません。詳細はgit-init [1]の "TEMPLATE DIRECTORY"セクションを参照してください。このドキュメントの残りの部分で「デフォルトのフック」について言及しているときは、Gitに同梱されているデフォルトのテンプレートについて話しています。

The currently supported hooks are described below.現在サポートされているフックは以下の通りです。

HOOKSフック

applypatch-msg

This hook is invoked by git-am[1]. It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with a non-zero status causes git am to abort before applying the patch.このフックはgit-am [1]によって呼び出されます。それは単一のパラメータ、提案されたコミットログメッセージを保持するファイルの名前を取ります。ゼロ以外のステータスで終了するとgit am、パッチを適用する前に中止されます。

The hook is allowed to edit the message file in place, and can be used to normalize the message into some project standard format. It can also be used to refuse the commit after inspecting the message file.フックはメッセージファイルをその場で編集することを許可されており、メッセージを何らかのプロジェクト標準フォーマットに正規化するために使用することができます。メッセージファイルを検査した後にコミットを拒否するためにも使用できます。

The default applypatch-msg hook, when enabled, runs the commit-msg hook, if the latter is enabled.デフォルトのapplypatch-msgフックは、有効になっていると、それが有効になっている場合にcommit-msgフックを実行します。

pre-applypatch事前適用パッチ

This hook is invoked by git-am[1]. It takes no parameter, and is invoked after the patch is applied, but before a commit is made.このフックはgit-am [1]によって呼び出されます。これはパラメータを取らず、パッチが適用された後、コミットが行われる前に呼び出されます。

If it exits with non-zero status, then the working tree will not be committed after applying the patch.ゼロ以外のステータスで終了した場合、パッチを適用した後に作業ツリーはコミットされません。

It can be used to inspect the current working tree and refuse to make a commit if it does not pass certain test.現在の作業ツリーを検査し、それが特定のテストに合格しない場合はコミットを拒否するために使用できます。

The default pre-applypatch hook, when enabled, runs the pre-commit hook, if the latter is enabled.デフォルトのpre-applypatchフックが有効になっていると、後者が有効な場合はpre-commitフックが実行されます。

post-applypatch適用後パッチ

This hook is invoked by git-am[1]. It takes no parameter, and is invoked after the patch is applied and a commit is made.このフックはgit-am [1]によって呼び出されます。これはパラメータを取らず、パッチが適用されてコミットが行われた後に呼び出されます。

This hook is meant primarily for notification, and cannot affect the outcome of git am.このフックは主に通知を目的としており、の結果に影響を与えることはできませんgit am

pre-commitプリコミット

This hook is invoked by git-commit[1], and can be bypassed with the --no-verify option. It takes no parameters, and is invoked before obtaining the proposed commit log message and making a commit. Exiting with a non-zero status from this script causes the git commit command to abort before creating a commit.このフックはgit-commit [1]によって呼び出され、--no-verifyオプションでバイパスすることができます。これはパラメータを取らず、提案されたコミットログメッセージを取得してコミットする前に呼び出されます。このスクリプトからゼロ以外のステータスで終了すると、git commitコミットを作成する前にコマンドが中止されます。

The default pre-commit hook, when enabled, catches introduction of lines with trailing whitespaces and aborts the commit when such a line is found.デフォルトのpre-commitフックは、有効になっていると、末尾の空白を含む行の導入をキャッチし、そのような行が見つかったときにコミットを中止します。

All the git commit hooks are invoked with the environment variable GIT_EDITOR=: if the command will not bring up an editor to modify the commit message.コマンドがコミットメッセージを変更するためのエディタを表示しない場合はgit commit、すべてのフックが環境変数で呼び出されGIT_EDITOR=:ます。

prepare-commit-msg

This hook is invoked by git-commit[1] right after preparing the default log message, and before the editor is started.このフックは、デフォルトのログメッセージを作成した直後、そしてエディタが起動する前に、git-commit [1]によって呼び出されます。

It takes one to three parameters. The first is the name of the file that contains the commit log message. The second is the source of the commit message, and can be: message (if a -m or -F option was given); template (if a -t option was given or the configuration option commit.template is set); merge (if the commit is a merge or a .git/MERGE_MSG file exists); squash (if a .git/SQUASH_MSG file exists); or commit, followed by a commit SHA-1 (if a -c, -C or --amend option was given).1から3個のパラメーターを取ります。最初のものはコミットログメッセージを含むファイルの名前です。2番目はコミットメッセージの送信元で、次のいずれかになります。message-mまたは-Fオプションが指定されている場合)template-tオプションが指定された場合、または設定オプションcommit.templateが設定されている場合)merge(コミットがマージであるか.git/MERGE_MSGファイルが存在する場合)squash.git/SQUASH_MSGファイルが存在する場合)又はcommit、コミットSHA-1、続いて(場合-c-Cまたは--amendオプションが与えられました)。

If the exit status is non-zero, git commit will abort.終了ステータスがゼロ以外の場合、git commit中止します。

The purpose of the hook is to edit the message file in place, and it is not suppressed by the --no-verify option. A non-zero exit means a failure of the hook and aborts the commit. It should not be used as replacement for pre-commit hook.フックの目的はメッセージファイルをその場で編集することであり、それは--no-verifyオプションによって抑制されません。ゼロ以外の終了は、フックの失敗を意味し、コミットを中止します。それはpre-commitフックの代わりとして使われるべきではありません。

The sample prepare-commit-msg hook that comes with Git removes the help message found in the commented portion of the commit template.prepare-commit-msgGitに付属のサンプルフックは、コミットテンプレートのコメント部分にあるヘルプメッセージを削除します。

commit-msg

This hook is invoked by git-commit[1] and git-merge[1], and can be bypassed with the --no-verify option. It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with a non-zero status causes the command to abort.このフックはgit-commit [1]git-merge [1]によって呼び出され、--no-verifyオプションでバイパスすることができます。それは単一のパラメータ、提案されたコミットログメッセージを保持するファイルの名前を取ります。ゼロ以外のステータスで終了すると、コマンドは中止されます。

The hook is allowed to edit the message file in place, and can be used to normalize the message into some project standard format. It can also be used to refuse the commit after inspecting the message file.フックはメッセージファイルをその場で編集することを許可されており、メッセージを何らかのプロジェクト標準フォーマットに正規化するために使用することができます。メッセージファイルを検査した後にコミットを拒否するためにも使用できます。

The default commit-msg hook, when enabled, detects duplicate "Signed-off-by" lines, and aborts the commit if one is found.デフォルトのcommit-msgフックが有効になっていると、重複した "Signed-off-by"行を検出し、見つかった場合はコミットを中止します。

post-commitコミット後

This hook is invoked by git-commit[1]. It takes no parameters, and is invoked after a commit is made.このフックはgit-commit [1]によって呼び出されます。これはパラメータを取らず、コミットが行われた後に呼び出されます。

This hook is meant primarily for notification, and cannot affect the outcome of git commit.このフックは主に通知を目的としており、の結果に影響を与えることはできませんgit commit

pre-rebaseプレベース

This hook is called by git-rebase[1] and can be used to prevent a branch from getting rebased. The hook may be called with one or two parameters. The first parameter is the upstream from which the series was forked. The second parameter is the branch being rebased, and is not set when rebasing the current branch.このフックはgit-rebase [1]によって呼び出され、ブランチがリベースされるのを防ぐために使用することができます。フックは1つか2つのパラメータで呼び出されます。最初のパラメータは系列が分岐した上流の上流です。2番目のパラメータは、リベースされるブランチです。現在のブランチをリベースするときには設定されません。

post-checkoutチェックアウト後

This hook is invoked when a git-checkout[1] is run after having updated the worktree. The hook is given three parameters: the ref of the previous HEAD, the ref of the new HEAD (which may or may not have changed), and a flag indicating whether the checkout was a branch checkout (changing branches, flag=1) or a file checkout (retrieving a file from the index, flag=0). This hook cannot affect the outcome of git checkout.このフックは、ワークツリーを更新した後にgit-checkout [1]が実行されたときに呼び出されます。フックには3つのパラメータが与えられます:前のHEADの参照、新しいHEADの参照(変更されているかどうかにかかわらず)、およびチェックアウトがブランチチェックアウトであったかどうかを示すフラグ(branchesの変更、flag = 1)ファイルチェックアウト(インデックスからファイルを取得する、flag = 0)このフックはの結果に影響を与えることはできませんgit checkout

It is also run after git-clone[1], unless the --no-checkout (-n) option is used. The first parameter given to the hook is the null-ref, the second the ref of the new HEAD and the flag is always 1. Likewise for git worktree add unless --no-checkout is used.()オプションが使用されていない限り、git-clone [1]の後にも実行されます。フックに与えられた最初のパラメータがnull-REF、新しいヘッドの第2のREFであり、フラグは常にための同様に1でない限り、使用されています。--no-checkout-ngit worktree add--no-checkout

This hook can be used to perform repository validity checks, auto-display differences from the previous HEAD if different, or set working dir metadata properties.このフックは、リポジトリの有効性チェック、異なる場合は以前のHEADとの差分の自動表示、または作業ディレクトリのメタデータプロパティの設定に使用できます。

post-mergeマージ後

This hook is invoked by git-merge[1], which happens when a git pull is done on a local repository. The hook takes a single parameter, a status flag specifying whether or not the merge being done was a squash merge. This hook cannot affect the outcome of git merge and is not executed, if the merge failed due to conflicts.このフックはgit-merge [1]によって起動されgit pullます。これはaがローカルリポジトリで行われたときに発生します。フックは単一のパラメータ、行われるマージがスカッシュマージかどうかを指定するステータスフラグを取ります。git merge競合が原因でマージが失敗した場合、このフックはの結果に影響を与えることはできず、実行されません。

This hook can be used in conjunction with a corresponding pre-commit hook to save and restore any form of metadata associated with the working tree (e.g.: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl for an example of how to do this.このフックを対応するpre-commitフックと組み合わせて使用??して、作業ツリーに関連付けられている任意の形式のメタデータ(例:パーミッション/所有権、ACLSなど)を保存および復元することができます。これを行う方法の例についてはcontrib / hooks / setgitperms.perlを参照してください。

pre-pushプリプッシュ

This hook is called by git-push[1] and can be used to prevent a push from taking place. The hook is called with two parameters which provide the name and location of the destination remote, if a named remote is not being used both values will be the same.このフックはgit-push [1]によって呼び出され、プッシュが行われないようにするために使用できます。名前付きリモートが使用されていない場合、フックは宛先リモートの名前と場所を提供する2つのパラメータを指定して呼び出されます。両方の値は同じになります。

Information about what is to be pushed is provided on the hook’s standard input with lines of the form:何をプッシュするかについての情報は、フックの標準入力に次の形式の行で提供されます。

<local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF

For instance, if the command git push origin master:foreign were run the hook would receive a line like the following:たとえば、コマンドgit push origin master:foreignが実行された場合、フックは次のような行を受け取ります。

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

although the full, 40-character SHA-1s would be supplied. If the foreign ref does not yet exist the <remote SHA-1> will be 40 0. If a ref is to be deleted, the <local ref> will be supplied as (delete) and the <local SHA-1> will be 40 0. If the local commit was specified by something other than a name which could be expanded (such as HEAD~, or a SHA-1) it will be supplied as it was originally given.完全な40文字のSHA-1が提供されます。外国人の参照がまだ存在しない場合は<remote SHA-1>40になり0ます。参照を削除する場合、<local ref>はとして提供され(delete)、は<local SHA-1>40になり0ます。ローカルコミットが拡張可能な名前(HEAD~またはSHA-1など)以外のもので指定されている場合は、元のとおりに提供されます。

If this hook exits with a non-zero status, git push will abort without pushing anything. Information about why the push is rejected may be sent to the user by writing to standard error.このフックが0以外のステータスで終了した場合は、git push何もプッシュせずに中断します。プッシュが拒否された理由に関する情報は、標準エラーへの書き込みによってユーザーに送信される場合があります。

pre-receive受け取り前

This hook is invoked by git-receive-pack[1] when it reacts to git push and updates reference(s) in its repository. Just before starting to update refs on the remote repository, the pre-receive hook is invoked. Its exit status determines the success or failure of the update.このフックは、git-receive-pack [1]git pushがリポジトリ内の参照に反応して更新するときに呼び出されます。リモートリポジトリの参照の更新を開始する直前に、受信前フックが呼び出されます。その終了ステータスは更新の成功または失敗を決定します。

This hook executes once for the receive operation. It takes no arguments, but for each ref to be updated it receives on standard input a line of the format:このフックは受信操作に対して1回実行されます。引数は取りませんが、更新される各refに対して、標準入力に次の形式の行を受け取ります。

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

where <old-value> is the old object name stored in the ref, <new-value> is the new object name to be stored in the ref and <ref-name> is the full name of the ref. When creating a new ref, <old-value> is 40 0.ここ<old-value>で、は参照に格納されている古いオブジェクト名、参照に格納される<new-value>新しいオブジェクト名、参照<ref-name>のフルネームです。新しいrefを作成するとき<old-value>は40 0です。

If the hook exits with non-zero status, none of the refs will be updated. If the hook exits with zero, updating of individual refs can still be prevented by the update hook.フックが0以外のステータスで終了した場合、参照はどれも更新されません。フックがゼロで終了しても、updateフックによって個々の参照の更新を防ぐことができます。

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.標準出力と標準エラー出力の両方がgit send-packもう一方の端に転送されるので、単にechoユーザーにメッセージを送ることができます。

The number of push options given on the command line of git push --push-option=... can be read from the environment variable GIT_PUSH_OPTION_COUNT, and the options themselves are found in GIT_PUSH_OPTION_0, GIT_PUSH_OPTION_1,…​ If it is negotiated to not use the push options phase, the environment variables will not be set. If the client selects to use push options, but doesn’t transmit any, the count variable will be set to zero, GIT_PUSH_OPTION_COUNT=0.コマンドラインで与えられたプッシュ・オプションの数についてgit push --push-option=...、環境変数から読み取ることができGIT_PUSH_OPTION_COUNT、かつ自身がで発見されたオプションはGIT_PUSH_OPTION_0GIT_PUSH_OPTION_1それがプッシュオプションフェーズを使用しないように交渉された場合、...、環境変数が設定されません。クライアントがプッシュオプションを使用することを選択したが、何も送信しない場合、count変数はゼロに設定されますGIT_PUSH_OPTION_COUNT=0

See the section on "Quarantine Environment" in git-receive-pack[1] for some caveats.注意点については、git-receive-pack [1]の "隔離環境"の節を参照してください。

update更新

This hook is invoked by git-receive-pack[1] when it reacts to git push and updates reference(s) in its repository. Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update.このフックは、git-receive-pack [1]git pushがリポジトリ内の参照に反応して更新するときに呼び出されます。リモートリポジトリのrefを更新する直前に、updateフックが呼び出されます。その終了ステータスは、ref更新の成功または失敗を決定します。

The hook executes once for each ref to be updated, and takes three parameters:フックは更新されるrefごとに1回実行され、3つのパラメータを取ります。

  • the name of the ref being updated,更新されている参照の名前

  • the old object name stored in the ref,参照に格納されている古いオブジェクト名

  • and the new object name to be stored in the ref.refに格納される新しいオブジェクト名

A zero exit from the update hook allows the ref to be updated. Exiting with a non-zero status prevents git receive-pack from updating that ref.updateフックからのゼロ出口は、refの更新を可能にします。ゼロ以外のステータスで終了すると、git receive-packその参照を更新できなくなります。

This hook can be used to prevent forced update on certain refs by making sure that the object name is a commit object that is a descendant of the commit object named by the old object name. That is, to enforce a "fast-forward only" policy.このフックは、オブジェクト名が古いオブジェクト名で指定されたコミットオブジェクトの子孫であるコミットオブジェクトであることを確認することによって、特定の参照に対する強制的な更新を防ぐために使用できます。つまり、「早送りのみ」のポリシーを強制することです。

It could also be used to log the old..new status. However, it does not know the entire set of branches, so it would end up firing one e-mail per ref when used naively, though. The post-receive hook is more suited to that.古いステータスを記録するためにも使用できます。しかしながら、それはブランチの全セットを知らないので、素朴に使用された場合には、1回の参照につき1つの電子メールを送信することになります。ポスト受けるフックがそれに適しています。

In an environment that restricts the users' access only to git commands over the wire, this hook can be used to implement access control without relying on filesystem ownership and group membership. See git-shell[1] for how you might use the login shell to restrict the user’s access to only git commands.ネットワーク経由のgitコマンドのみにユーザーのアクセスを制限する環境では、このフックを使用してファイルシステムの所有権やグループメンバーシップに頼らずにアクセス制御を実装できます。ログインシェルを使用してユーザーのアクセスをgitコマンドのみに制限する方法については、git-shell [1]を参照してください。

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.標準出力と標準エラー出力の両方がgit send-packもう一方の端に転送されるので、単にechoユーザーにメッセージを送ることができます。

The default update hook, when enabled—​and with hooks.allowunannotated config option unset or set to false—​prevents unannotated tags to be pushed.デフォルトのupdateフックは、有効にされているとき - そしてhooks.allowunannotatedconfigオプションがunsetまたはfalseに設定されているとき - 注釈のないタグがプッシュされるのを防ぎます。

post-receive受信後

This hook is invoked by git-receive-pack[1] when it reacts to git push and updates reference(s) in its repository. It executes on the remote repository once after all the refs have been updated.このフックは、git-receive-pack [1]git pushがリポジトリ内の参照に反応して更新するときに呼び出されます。すべての参照が更新された後、リモートリポジトリで1回実行されます。

This hook executes once for the receive operation. It takes no arguments, but gets the same information as the pre-receive hook does on its standard input.このフックは受信操作に対して1回実行されます。引数は取りませんが、受信前フックが標準入力に対して行うのと同じ情報を取得します。

This hook does not affect the outcome of git receive-pack, as it is called after the real work is done.このフックはgit receive-pack、実際の作業が終了した後に呼び出されるので、の結果には影響しません。

This supersedes the post-update hook in that it gets both old and new values of all the refs in addition to their names.これは更新後フックに取って代わり、それはそれらの名前に加えてすべての参照の新旧両方の値を取得します。

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.標準出力と標準エラー出力の両方がgit send-packもう一方の端に転送されるので、単にechoユーザーにメッセージを送ることができます。

The default post-receive hook is empty, but there is a sample script post-receive-email provided in the contrib/hooks directory in Git distribution, which implements sending commit emails.デフォルトの受信後フックは空ですが、Gitディストリビューションpost-receive-emailcontrib/hooksディレクトリに提供されているサンプルスクリプトがあります。これは送信コミットメールを実装しています。

The number of push options given on the command line of git push --push-option=... can be read from the environment variable GIT_PUSH_OPTION_COUNT, and the options themselves are found in GIT_PUSH_OPTION_0, GIT_PUSH_OPTION_1,…​ If it is negotiated to not use the push options phase, the environment variables will not be set. If the client selects to use push options, but doesn’t transmit any, the count variable will be set to zero, GIT_PUSH_OPTION_COUNT=0.コマンドラインで与えられたプッシュ・オプションの数についてgit push --push-option=...、環境変数から読み取ることができGIT_PUSH_OPTION_COUNT、かつ自身がで発見されたオプションはGIT_PUSH_OPTION_0GIT_PUSH_OPTION_1それがプッシュオプションフェーズを使用しないように交渉された場合、...、環境変数が設定されません。クライアントがプッシュオプションを使用することを選択したが、何も送信しない場合、count変数はゼロに設定されますGIT_PUSH_OPTION_COUNT=0

post-update更新後

This hook is invoked by git-receive-pack[1] when it reacts to git push and updates reference(s) in its repository. It executes on the remote repository once after all the refs have been updated.このフックは、git-receive-pack [1]git pushがリポジトリ内の参照に反応して更新するときに呼び出されます。すべての参照が更新された後、リモートリポジトリで1回実行されます。

It takes a variable number of parameters, each of which is the name of ref that was actually updated.それは可変数のパラメータを取り、それぞれのパラメータは実際に更新されたrefの名前です。

This hook is meant primarily for notification, and cannot affect the outcome of git receive-pack.このフックは主に通知を目的としており、の結果に影響を与えることはできませんgit receive-pack

The post-update hook can tell what are the heads that were pushed, but it does not know what their original and updated values are, so it is a poor place to do log old..new. The post-receive hook does get both original and updated values of the refs. You might consider it instead if you need them.更新後のフックがプッシュされたヘッドで何を伝えることができますが、それは彼らの元と更新された値が何であるかを知らないので、それはold..newログインを行うために貧しい場所です。ポスト受けるフックは、引用文献の両方の元と更新された値を取得ありません。あなたがそれらを必要とするならあなたは代わりにそれを考慮するかもしれません。

When enabled, the default post-update hook runs git update-server-info to keep the information used by dumb transports (e.g., HTTP) up to date. If you are publishing a Git repository that is accessible via HTTP, you should probably enable this hook.有効にすると、デフォルトの更新後フックがgit update-server-infoダムトランスポート(HTTPなど)で使用される情報を最新に保つために実行されます。HTTP経由でアクセス可能なGitリポジトリを公開している場合は、おそらくこのフックを有効にする必要があります。

Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user.標準出力と標準エラー出力の両方がgit send-packもう一方の端に転送されるので、単にechoユーザーにメッセージを送ることができます。

push-to-checkoutプッシュトゥチェックアウト

This hook is invoked by git-receive-pack[1] when it reacts to git push and updates reference(s) in its repository, and when the push tries to update the branch that is currently checked out and the receive.denyCurrentBranch configuration variable is set to updateInstead. Such a push by default is refused if the working tree and the index of the remote repository has any difference from the currently checked out commit; when both the working tree and the index match the current commit, they are updated to match the newly pushed tip of the branch. This hook is to be used to override the default behaviour.このフックは、git-receive-pack [1]git pushがリポジトリ内の参照に反応して更新したとき、およびプッシュが現在チェックアウトされていてreceive.denyCurrentBranch設定変数がに設定されているブランチを更新しようとしたときに呼び出されますupdateInstead。作業ツリーとリモートリポジトリのインデックスに現在チェックアウトされているコミットとの違いがある場合、デフォルトではそのようなプッシュは拒否されます。作業ツリーとインデックスの両方が現在のコミットと一致すると、それらはブランチの新しくプッシュされたチップと一致するように更新されます。このフックはデフォルトの振る舞いを上書きするために使用されます。

The hook receives the commit with which the tip of the current branch is going to be updated. It can exit with a non-zero status to refuse the push (when it does so, it must not modify the index or the working tree). Or it can make any necessary changes to the working tree and to the index to bring them to the desired state when the tip of the current branch is updated to the new commit, and exit with a zero status.フックは現在のブランチの先端が更新されることになっているコミットを受け取ります。プッシュを拒否するためにゼロ以外のステータスで終了することができます(そうするときは、インデックスや作業ツリーを変更してはいけません)。あるいは、現在のブランチの先端が新しいコミットに更新されたときに作業ツリーとインデックスに必要な変更を加えて目的の状態にし、ステータス0で終了することもできます。

For example, the hook can simply run git read-tree -u -m HEAD "$1" in order to emulate git fetch that is run in the reverse direction with git push, as the two-tree form of git read-tree -u -m is essentially the same as git checkout that switches branches while keeping the local changes in the working tree that do not interfere with the difference between the branches.たとえば、2ツリー形式は基本的に分岐を切り替えるのと同じgit read-tree -u -m HEAD ""であるため、フックは単純にgit fetch逆方向に実行されることをエミュレートするために実行できます。ブランチ間の違いgit pushgit read-tree -u -mgit checkout

pre-auto-gcプレオートgc

This hook is invoked by git gc --auto (see git-gc[1]). It takes no parameter, and exiting with non-zero status from this script causes the git gc --auto to abort.このフックはgit gc --autogit-gc [1]を参照)によって呼び出されます。パラメータを取らず、このスクリプトから0以外のステータスで終了すると、git gc --autoが中止されます。

post-rewrite書き換え後

This hook is invoked by commands that rewrite commits (git-commit[1] when called with --amend and git-rebase[1]; currently git filter-branch does not call it!). Its first argument denotes the command it was invoked by: currently one of amend or rebase. Further command-dependent arguments may be passed in the future.(このフックはコミットを書き換えるコマンドによって呼び出されるgitのコミット[1]で呼び出されたとき--amend、[1]のgit-rebaseし、現在はgit filter-branchないではない、それを呼んで!)。その最初の引数は、それが呼び出されたコマンドを表します。現在は、amendまたはのいずれかrebaseです。さらなるコマンド依存の引数が将来渡されるかもしれません。

The hook receives a list of the rewritten commits on stdin, in the formatフックはstdinで書き換えられたコミットのリストを以下のフォーマットで受け取ります。

<old-sha1> SP <new-sha1> [ SP <extra-info> ] LF

The extra-info is again command-dependent. If it is empty, the preceding SP is also omitted. Currently, no commands pass any extra-info.補足情報は、再度コマンドに依存します。空の場合は、先行するSPも省略されます。現在のところ、どのコマンドも追加情報を渡しません。

The hook always runs after the automatic note copying (see "notes.rewrite.<command>" in git-config[1]) has happened, and thus has access to these notes.フックは常に自動ノートコピー(git-config [1]の "notes.rewrite。<command>"を参照)が行われた後に実行され、したがってこれらのノートにアクセスできます。

The following command-specific comments apply:以下のコマンド固有のコメントが適用されます。

rebase リベース

For the squash and fixup operation, all commits that were squashed are listed as being rewritten to the squashed commit. This means that there will be several lines sharing the same new-sha1.スカッシュおよび修正操作の場合、スカッシュされたすべてのコミットは、スカッシュされたコミットに書き換えられたものとしてリストされます。これは、同じnew-sha1を共有する複数の行があることを意味します。

The commits are guaranteed to be listed in the order that they were processed by rebase.コミットは、リベースによって処理された順序でリストされることが保証されています。

sendemail-validate

This hook is invoked by git-send-email[1]. It takes a single parameter, the name of the file that holds the e-mail to be sent. Exiting with a non-zero status causes git send-email to abort before sending any e-mails.このフックはgit-send-email [1]によって呼び出されます。これは単一のパラメーター、つまり送信されるEメールを保持するファイルの名前を取ります。ゼロ以外のステータスで終了すると、git send-email電子メールを送信する前に中止されます。

fsmonitor-watchman

This hook is invoked when the configuration option core.fsmonitor is set to .git/hooks/fsmonitor-watchman. It takes two arguments, a version (currently 1) and the time in elapsed nanoseconds since midnight, January 1, 1970.このフックは、設定オプションcore.fsmonitorがに設定されているときに呼び出されます.git/hooks/fsmonitor-watchman。これは2つの引数、バージョン(現在は1)と1970年1月1日午前0時からの経過ナノ秒単位の時間を取ります。

The hook should output to stdout the list of all files in the working directory that may have changed since the requested time. The logic should be inclusive so that it does not miss any potential changes. The paths should be relative to the root of the working directory and be separated by a single NUL.フックは、要求された時間以降に変更された可能性がある作業ディレクトリ内のすべてのファイルのリストを標準出力に出力する必要があります。論理は、潜在的な変更を見逃さないように包括的であるべきです。パスは作業ディレクトリのルートからの相対パスで、単一のNULで区切られている必要があります。

It is OK to include files which have not actually changed. All changes including newly-created and deleted files should be included. When files are renamed, both the old and the new name should be included.実際には変更されていないファイルを含めても構いません。新しく作成されたファイルや削除されたファイルを含むすべての変更を含める必要があります。ファイルの名前を変更するときは、古い名前と新しい名前の両方を含める必要があります。

Git will limit what files it checks for changes as well as which directories are checked for untracked files based on the path names given.Gitは、与えられたパス名に基づいて、どのファイルが変更をチェックするのか、そしてどのディレクトリがチェックされていないファイルをチェックされるのかを制限します。

An optimized way to tell git "all files have changed" is to return the filename /.gitに「すべてのファイルが変更された」と伝えるための最適化された方法は、ファイル名を返すこと/です。

The exit status determines whether git will use the data from the hook to limit its search. On error, it will fall back to verifying all files and folders.終了ステータスは、gitが検索を制限するためにフックからのデータを使用するかどうかを決定します。エラーが発生した場合は、すべてのファイルとフォルダの検証に戻ります。

p4-pre-submit

This hook is invoked by git-p4 submit. It takes no parameters and nothing from standard input. Exiting with non-zero status from this script prevent git-p4 submit from launching. Run git-p4 submit --help for details.このフックはによって呼び出されgit-p4 submitます。標準入力からはパラメータも取りません。このスクリプトからゼロ以外のステータスで終了するとgit-p4 submit起動できなくなります。git-p4 submit --help詳細については実行してください。

GIT

Part of the git[1] suite一部のgit [1]スイート

スポンサーリンク

関連記事

スポンサーリンク

scrollbar-3dlight-color スクロールバーの左端と上端の色を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る