Git

git-rev-parse は 2.45.3 で最終更新されました

名前

git-rev-parse - パラメータの選択と整形

概要

git rev-parse [<options>] <arg>…

説明

多くのGitのポーセリンコマンドは、フラグ (つまり、ダッシュ - で始まるパラメータ) と、内部で使用する基盤となる git rev-list コマンド用のパラメータ、および git rev-list の下流で使用する他のコマンド用のフラグとパラメータが混在しています。このコマンドの主な目的は、呼び出しプログラムがそれらを区別できるようにすることです。上記の「コマンドラインオプションの解析を助ける」とは関係のない、他の操作モードもいくつかあります。

特に指定がない限り、ほとんどのオプションと操作モードでは、gitリポジトリ内またはgitリポジトリの管理下にある作業ツリー内でこのコマンドを実行する必要があります。そうでない場合は致命的なエラーが発生します。

オプション

操作モード

これらのオプションはそれぞれ、コマンドラインの最初に指定する必要があります。

--parseopt: オプション解析モードで git rev-parse を使用します (下記の PARSEOPT セクションを参照)。このモードのコマンドは、リポジトリまたはリポジトリによって制御される作業ツリーの外部で使用できます。
--sq-quote: シェルクォーティングモードで git rev-parse を使用します (下記の SQ-QUOTE セクションを参照)。下記の --sq オプションとは対照的に、このモードはクォーティングのみを行います。コマンド入力に対して他に何も行われません。このモードのコマンドは、リポジトリまたはリポジトリによって制御される作業ツリーの外部で使用できます。

--parseopt のオプション

--keep-dashdash: --parseopt モードでのみ意味があります。オプションパーサーに、最初に見つかった -- をスキップする代わりにエコー出力するように指示します。
--stop-at-non-option: --parseopt モードでのみ意味があります。オプションパーサーが最初の非オプション引数で停止するようにします。これは、それ自体がオプションを取るサブコマンドを解析するために使用できます。
--stuck-long: --parseopt モードでのみ意味があります。オプションが利用可能な場合は長い形式で、引数が連結されて出力されます。

フィルタリングのオプション

--revs-only: git rev-list コマンドを対象としないフラグやパラメータは出力しません。
--no-revs: git rev-list コマンドを対象とするフラグやパラメータは出力しません。
--flags: 非フラグパラメータは出力しません。
--no-flags: フラグパラメータは出力しません。

出力のオプション

--default <arg>

ユーザーによってパラメータが与えられない場合、代わりに <arg> を使用します。

--prefix <arg>

git rev-parse が作業ツリーの <arg> サブディレクトリから呼び出されたかのように動作します。相対ファイル名は <arg> で始まるかのように解決され、その形式で出力されます。

これは、サブディレクトリで実行されるコマンドへの引数を、リポジトリのトップレベルに移動した後でも使用できるように変換するために使用できます。例えば、

prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-toplevel)"
# rev-parse provides the -- needed for 'set'
eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"

--verify

パラメータが正確に1つ提供され、それがオブジェクトデータベースにアクセスするために使用できる生SHA-1 (20バイト) に変換できることを確認します。そうであれば、それを標準出力に出力します。そうでなければ、エラーを発生させます。

出力が実際にオブジェクトデータベース内のオブジェクトを指し、かつ、必要な特定の種類のオブジェクトとして使用できることを確認したい場合は、パラメータに ^{type} ピーリング演算子を追加できます。例えば、 git rev-parse "$VAR^{commit}" は、$VAR がコミットのような既存のオブジェクト (つまり、コミット、またはコミットを指す注釈付きタグ) を指すことを保証します。 $VAR が既存の任意のタイプのオブジェクトを指すことを確認するには、 git rev-parse "$VAR^{object}" を使用できます。

信頼できないソースからの名前を検証する場合、名前引数が別のオプションと誤解されないように --end-of-options を使用することが賢明であることに注意してください。

-q

--quiet

--verify モードでのみ意味があります。最初の引数が有効なオブジェクト名でない場合でもエラーメッセージを出力せず、代わりに非ゼロステータスで静かに終了します。有効なオブジェクト名のSHA-1は、成功時に標準出力に出力されます。

--sq

通常、出力はフラグとパラメータごとに1行で作成されます。このオプションは、出力をシェルによって消費するために適切に引用された単一の行にします。パラメータに空白や改行が含まれると予想される場合に便利です (例えば、 git diff-* でピッケル -S を使用する場合)。 --sq-quote オプションとは対照的に、コマンド入力は通常通り解釈されます。

--short[=<length>]

--verify と同じですが、オブジェクト名を少なくとも length 文字の一意のプレフィックスに短縮します。最小の長さは4で、デフォルトは core.abbrev 設定変数の有効値です (git-config[1] を参照)。

--not

オブジェクト名を表示する際、それらに ^ をプレフィックスとして付け、既に ^ プレフィックスを持つオブジェクト名からは ^ プレフィックスを取り除きます。

--abbrev-ref[=(strict|loose)]

オブジェクト名に対する曖昧さのない短い名前。オプション `core.warnAmbiguousRefs` は厳密な省略モードを選択するために使用されます。

--symbolic

通常、オブジェクト名はSHA-1形式 (可能な場合は ^ プレフィックス付き) で出力されます。このオプションを使用すると、可能な限り元の入力に近い形式で出力されます。

--symbolic-full-name

これは--symbolicに似ていますが、refではない入力 (つまり、ブランチ名やタグ名、または、不運にも "master" という名前のタグが存在する場合に "master" ブランチを指したいときの、より明示的に曖昧さを解消する "heads/master" 形式) は省略し、完全なref名 (例: "refs/heads/master") として表示します。

--output-object-format=(sha1|sha256|storage)

現在のリポジトリがサポートする任意のオブジェクト形式からOIDを入力できるようにします。

Specifying "sha1" translates if necessary and returns a sha1 oid.

Specifying "sha256" translates if necessary and returns a sha256 oid.

Specifying "storage" translates if necessary and returns an oid in
encoded in the storage hash algorithm.

オブジェクトのオプション

--all: refs/ に見つかるすべての参照を表示します。
--branches[=<pattern>]
--tags[=<pattern>]
--remotes[=<pattern>]: それぞれ、すべてのブランチ、タグ、またはリモート追跡ブランチ (つまり、それぞれ refs/heads、 refs/tags、または refs/remotes に見つかる参照) を表示します。

pattern が指定されている場合、指定されたシェルglobに一致する参照のみが表示されます。パターンにglob文字 ( ?、 *、または [ ) が含まれていない場合、 /* を追加することでプレフィックス一致に変換されます。
--glob=<pattern>: シェルglobパターン pattern に一致するすべての参照を表示します。パターンが refs/ で始まらない場合、自動的に前に付けられます。パターンにglob文字 ( ?、 *、または [ ) が含まれていない場合、 /* を追加することでプレフィックス一致に変換されます。
--exclude=<glob-pattern>: 次に --all, --branches, --tags, --remotes, または --glob が考慮するはずの <glob-pattern> に一致する参照は含めません。このオプションの繰り返しは、次の --all, --branches, --tags, --remotes, または --glob オプションまで除外パターンを累積します (他のオプションや引数は累積されたパターンをクリアしません)。

与えられたパターンは、それぞれ --branches、 --tags、または --remotes に適用される場合、refs/heads、 refs/tags、または refs/remotes で始まってはならず、 --glob または --all に適用される場合、refs/ で始まらなければなりません。末尾の /* が意図されている場合は、明示的に与える必要があります。
--exclude-hidden=(fetch|receive|uploadpack): git-fetch、 git-receive-pack、または git-upload-pack によって隠される参照を含めません。これには、適切な fetch.hideRefs、 receive.hideRefs、または uploadpack.hideRefs の設定と transfer.hideRefs を参照します (git-config[1] を参照)。このオプションは、次の疑似参照オプション --all または --glob に影響し、それらを処理した後でクリアされます。
--disambiguate=<prefix>: 与えられたプレフィックスで始まる名前を持つすべてのオブジェクトを表示します。リポジトリ内のすべてのオブジェクトを誤ってリストアップするのを避けるため、<prefix> は少なくとも4桁の16進数である必要があります。

ファイルのオプション

--local-env-vars: リポジトリにローカルなGIT_*環境変数 (例: GIT_DIR または GIT_WORK_TREE、ただしGIT_EDITORではない) をリストします。設定されていても、変数の値ではなく名前のみがリストされます。
--path-format=(absolute|relative): 他の特定のオプションの動作を制御します。absoluteと指定した場合、これらのオプションによって出力されるパスは絶対パスで正規化されます。relativeと指定した場合、パスは可能であれば現在の作業ディレクトリからの相対パスになります。デフォルトはオプションごとに異なります。

このオプションは複数回指定でき、コマンドライン上の後続の引数にのみ影響を与えます。コマンドラインの終わりまで、またはこのオプションの次のインスタンスまでです。

以下のオプションは --path-format によって変更されます。

--git-dir: $GIT_DIR が定義されている場合はそれを表示します。定義されていない場合は .git ディレクトリへのパスを表示します。表示されるパスは、相対パスの場合、現在の作業ディレクトリからの相対パスです。

$GIT_DIR が定義されておらず、現在のディレクトリがGitリポジトリまたは作業ツリー内にないことが検出された場合、stderrにメッセージを出力し、ゼロ以外のステータスで終了します。
--git-common-dir: $GIT_COMMON_DIR が定義されている場合はそれを表示し、そうでなければ $GIT_DIR を表示します。
--resolve-git-dir <path>: <path> が有効なリポジトリであるか、有効なリポジトリを指すgitfileであるかを確認し、リポジトリの場所を出力します。<path> がgitfileである場合、実際の解決されたリポジトリへのパスが出力されます。
--git-path <path>: "$GIT_DIR/<path>" を解決し、$GIT_OBJECT_DIRECTORY、$GIT_INDEX_FILEなどの他のパス再配置変数を考慮に入れます。例えば、$GIT_OBJECT_DIRECTORYが/foo/barに設定されている場合、"git rev-parse --git-path objects/abc"は/foo/bar/abcを返します。
--show-toplevel: 作業ツリーのトップレベルディレクトリの (デフォルトでは絶対) パスを表示します。作業ツリーがない場合、エラーを報告します。
--show-superproject-working-tree: 現在のリポジトリをサブモジュールとして使用するスーパープロジェクトの作業ツリー (存在する場合) のルートの絶対パスを表示します。現在のリポジトリがどのプロジェクトでもサブモジュールとして使用されていない場合は何も出力しません。
--shared-index-path: 分割インデックスモードの場合、共有インデックスファイルへのパスを表示します。分割インデックスモードでない場合は空を表示します。

以下のオプションは --path-format の影響を受けません。

--absolute-git-dir: --git-dir と同じですが、出力は常に正規化された絶対パスです。
--is-inside-git-dir: 現在の作業ディレクトリがリポジトリディレクトリの下にある場合、「true」と出力し、それ以外の場合は「false」と出力します。
--is-inside-work-tree: 現在の作業ディレクトリがリポジトリの作業ツリー内にある場合、「true」と出力し、それ以外の場合は「false」と出力します。
--is-bare-repository: リポジトリがベアの場合、「true」と出力し、それ以外の場合は「false」と出力します。
--is-shallow-repository: リポジトリがシャローの場合、「true」と出力し、それ以外の場合は「false」と出力します。
--show-cdup: コマンドがサブディレクトリから呼び出された場合、現在のディレクトリに対するトップレベルディレクトリのパスを表示します (通常は "../" の連続、または空文字列)。
--show-prefix: コマンドがサブディレクトリから呼び出された場合、トップレベルディレクトリに対する現在のディレクトリのパスを表示します。
--show-object-format[=(storage|input|output)]: リポジトリで .git ディレクトリ内部での保存、入力、または出力に使用されるオブジェクト形式 (ハッシュアルゴリズム) を表示します。入力の場合、複数のアルゴリズムがスペース区切りで出力されることがあります。指定しない場合、デフォルトは "storage" です。
--show-ref-format: リポジトリに使用される参照ストレージ形式を表示します。

その他のオプション

--since=<datestring>
--after=<datestring>: 日付文字列を解析し、git rev-list に対応する --max-age= パラメータを出力します。
--until=<datestring>
--before=<datestring>: 日付文字列を解析し、git rev-list に対応する --min-age= パラメータを出力します。
<arg>…: 解析するフラグとパラメータ。

リビジョンの指定

リビジョンパラメータ <rev> は通常、ただし必ずしもそうではありませんが、コミットオブジェクトの名前を指します。これは 拡張SHA-1 構文と呼ばれるものを使用します。以下にオブジェクト名を綴る様々な方法を示します。リストの最後に近いものは、コミットに含まれるツリーとブロブの名前を指します。

注	このドキュメントでは、gitが認識する「生の」構文を示しています。シェルやその他のUIでは、特殊文字を保護し、単語分割を避けるために追加の引用符が必要になる場合があります。

<sha1>, 例: dae86e1950b1277e545cee180551750029cfe735, dae86e

完全なSHA-1オブジェクト名 (40バイトの16進文字列) または、リポジトリ内で一意な先頭部分文字列。例: dae86e1950b1277e545cee180551750029cfe735 と dae86e は、オブジェクト名が dae86e で始まる他のオブジェクトがリポジトリにない場合、同じコミットオブジェクトを指します。

<describeOutput>, 例: v1.7.4.2-679-g3bee7fb

git describe の出力。つまり、最も近いタグに、オプションでダッシュとコミット数、さらにダッシュ、 g、および短縮されたオブジェクト名が続きます。

<refname>, 例: master, heads/master, refs/heads/master

シンボリック参照名。例えば、 master は通常、 refs/heads/master で参照されるコミットオブジェクトを意味します。たまたま heads/master と tags/master の両方がある場合、どちらを指すかをGitに明確に伝えるために明示的に heads/master と指定できます。曖昧な場合、 <refname> は以下の規則で最初に見つかったものによって解決されます。

$GIT_DIR/<refname> が存在する場合、それが意図するものです (これは通常、 HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD, BISECT_HEAD, AUTO_MERGE にのみ役立ちます)。
それ以外の場合、refs/<refname> が存在すればそれ。
それ以外の場合、refs/tags/<refname> が存在すればそれ。
それ以外の場合、refs/heads/<refname> が存在すればそれ。
それ以外の場合、refs/remotes/<refname> が存在すればそれ。
それ以外の場合、refs/remotes/<refname>/HEAD が存在すればそれ。

HEAD

作業ツリーでの変更の基にしたコミットを指します。

FETCH_HEAD

最後に git fetch を呼び出したときにリモートリポジトリからフェッチしたブランチを記録します。

ORIG_HEAD

git am, git merge, git rebase, git reset のように HEAD を大幅に移動するコマンドによって作成され、操作前の HEAD の位置を記録するため、実行前の状態にブランチの先端を簡単に戻すことができます。

MERGE_HEAD

git merge を実行するときに、ブランチにマージしているコミットを記録します。

REBASE_HEAD

リベース中に、競合のため、またはインタラクティブなリベースでの edit コマンドのために、操作が現在停止しているコミットを記録します。

REVERT_HEAD

git revert を実行するときに、revertするコミットを記録します。

CHERRY_PICK_HEAD

git cherry-pick を実行するときに、チェリーピックするコミットを記録します。

BISECT_HEAD

git bisect --no-checkout を実行するときに、現在テストされているコミットを記録します。

AUTO_MERGE

マージ操作で競合が発生した場合に、 ort マージ戦略が作業ツリーに書き込んだ状態に対応するツリーオブジェクトを記録します。

上記の refs/* のケースはすべて、 $GIT_DIR/refs ディレクトリまたは $GIT_DIR/packed-refs ファイルのいずれかから来る可能性があることに注意してください。参照名のエンコーディングは指定されていませんが、UTF-8 が好まれます。一部の出力処理は参照名がUTF-8であると仮定する可能性があるためです。

@

単独の @ は HEAD のショートカットです。

[<refname>]@{<date>}, 例: master@{yesterday}, HEAD@{5 minutes ago}

参照名の後に、日付指定を括弧で囲んだサフィックス @ (例: {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} または {1979-02-26 18:30:00}) を付けると、特定の過去時点での参照の値が指定されます。このサフィックスは参照名の直後にのみ使用でき、参照には既存のログ ($GIT_DIR/logs/<ref>) が必要です。これは、特定の時点でのあなたのローカル参照の状態を検索することに注意してください。例えば、先週のあなたのローカル master ブランチに何があったか、といったことです。特定の期間中に行われたコミットを見たい場合は、 --since と --until を参照してください。

<refname>@{<n>}, 例: master@{1}

参照名の後に、順序指定を括弧で囲んだサフィックス @ (例: {1}, {15}) を付けると、その参照のn番目の以前の値が指定されます。例えば、 master@{1} は master の直前の値であり、 master@{5} は master の5番目の以前の値です。このサフィックスは参照名の直後にのみ使用でき、参照には既存のログ ($GIT_DIR/logs/<refname>) が必要です。

@{<n>}, 例: @{1}

現在のブランチのリフロッグエントリを取得するには、参照部分が空の @ 構造を使用できます。例えば、 blabla ブランチにいる場合、 @{1} は blabla@{1} と同じ意味です。

@{-<n>}, 例: @{-1}

構造 @{-<n>} は、現在のブランチの前にチェックアウトされた <n> 番目のブランチ/コミットを意味します。

[<branchname>]@{upstream}, 例: master@{upstream}, @{u}

ブランチ B は、リモート R ( branch.<name>.remote で設定) のブランチ X ( branch.<name>.merge で設定) の上に構築されるように設定できます。B@{u} は、リモート R から取得されたブランチ X に対応するリモート追跡ブランチを指し、通常は refs/remotes/R/X にあります。

[<branchname>]@{push}, 例: master@{push}, @{push}

サフィックス @{push} は、 branchname がチェックアウトされている間 (またはブランチ名が指定されていない場合は現在の HEAD ) に git push が実行された場合に「プッシュ先のブランチ」を報告します。 @{upstream} と同様に、リモートのそのブランチに対応するリモート追跡ブランチを報告します。

より明確にするための例を次に示します。

$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

この例では、ある場所からプルし、別の場所にプッシュする三角形のワークフローを設定していることに注意してください。非三角形のワークフローでは、 @{push} は @{upstream} と同じであり、必要ありません。

このサフィックスは大文字で記述しても受け入れられ、大文字小文字にかかわらず同じ意味です。

<rev>^[<n>], 例: HEAD^, v1.5.1^0

リビジョンパラメータへの接尾辞 ^ は、そのコミットオブジェクトの最初の親を意味します。 ^<n> は <n> 番目の親を意味します (つまり、 <rev>^ は <rev>^1 と同等です)。特別なルールとして、 <rev>^0 はコミット自体を意味し、 <rev> がコミットオブジェクトを参照するタグオブジェクトのオブジェクト名である場合に使用されます。

<rev>~[<n>], 例: HEAD~, master~3

リビジョンパラメータに対するサフィックス ~ は、そのコミットオブジェクトの最初の親を意味します。リビジョンパラメータに対するサフィックス ~<n> は、指定されたコミットオブジェクトのn世代前の祖先であるコミットオブジェクトを意味し、最初の親のみをたどります。つまり、 <rev>~3 は <rev>^^^ と同等であり、 <rev>^1^1^1 と同等です。この形式の使用例については以下を参照してください。

<rev>^{<type>}, 例: v0.99.8^{commit}

括弧で囲まれたオブジェクトタイプ名の後にサフィックス ^ を続けると、 <rev> にあるオブジェクトを再帰的に逆参照し、 <type> 型のオブジェクトが見つかるか、オブジェクトがこれ以上逆参照できなくなるまで (その場合は失敗)、逆参照します。例えば、 <rev> がコミットライクなオブジェクトの場合、 <rev>^{commit} は対応するコミットオブジェクトを記述します。同様に、 <rev> がツリーライクなオブジェクトの場合、 <rev>^{tree} は対応するツリーオブジェクトを記述します。 <rev>^0 は <rev>^{commit} の短縮形です。

<rev>^{object} を使用すると、 <rev> が存在するオブジェクトの名前であることを確認できます。 <rev> がタグである必要はなく、 <rev> を一度も逆参照する必要もありません。タグはすでにオブジェクトであるため、オブジェクトに到達するために一度も逆参照する必要はありません。

<rev>^{tag} は、 <rev> が既存のタグオブジェクトを識別することを確認するために使用できます。

<rev>^{}, 例: v0.99.8^{}

空の括弧の後に続くサフィックス ^ は、オブジェクトがタグである可能性があり、タグではないオブジェクトが見つかるまでタグを再帰的に逆参照することを意味します。

<rev>^{/<text>}, 例: HEAD^{/fix nasty bug}

リビジョンパラメータに対するサフィックス ^ に、スラッシュに続くテキストを含む括弧ペアが続く形式は、以下の :/fix nasty bug 構文と同じですが、 ^ の前の <rev> から到達可能な、最も新しい一致するコミットを返します。

:/<text>, 例: :/fix nasty bug

コロン、スラッシュ、テキストが続く形式は、指定された正規表現にコミットメッセージが一致するコミットを名前で指定します。この名前は、HEADを含むあらゆる参照から到達可能な、最も新しい一致するコミットを返します。正規表現はコミットメッセージの任意の部分に一致できます。文字列で始まるメッセージに一致させるには、例えば :/^foo を使用できます。特殊なシーケンス :/! は、一致するものを変更するための修飾子として予約されています。 :/!-foo は否定一致を実行し、 :/!!foo はリテラルの ! 文字の後に foo を一致させます。 :/! で始まるその他のシーケンスは現在予約されています。与えられたテキストによっては、シェルの単語分割ルールにより追加の引用符が必要になる場合があります。

<rev>:<path>, 例: HEAD:README, master:./README

コロンの後にパスが続くサフィックスは、コロンの前の部分によって名前が付けられたツリーライクなオブジェクト内の指定されたパスにあるブロブまたはツリーを名前で指定します。 ./ または ../ で始まるパスは、現在の作業ディレクトリからの相対パスです。指定されたパスは、作業ツリーのルートディレクトリからの相対パスに変換されます。これは、作業ツリーと同じツリー構造を持つコミットまたはツリーからブロブまたはツリーをアドレス指定するのに最も役立ちます。

:[<n>:]<path>, 例: :0:README, :README

コロン、オプションでステージ番号 (0から3) とコロン、そしてパスが続く形式は、指定されたパスのインデックス内のブロブオブジェクトを名前で指定します。ステージ番号 (とその後のコロン) が欠落している場合、ステージ0のエントリを名前で指定します。マージ中、ステージ1は共通の祖先、ステージ2はターゲットブランチのバージョン (通常は現在のブランチ)、ステージ3はマージされているブランチのバージョンです。

Jon Loeligerによる図を次に示します。コミットノードBとCの両方がコミットノードAの親です。親コミットは左から右に順序付けられています。

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A

A =      = A^0
B = A^   = A^1     = A~1
C =      = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2

範囲の指定

git log のような履歴をたどるコマンドは、単一のコミットだけでなく、一連のコミットに対して動作します。

これらのコマンドでは、前のセクションで説明した表記法を使用して単一のリビジョンを指定すると、指定されたコミットから到達可能なコミットのセットを意味します。

複数のリビジョンを指定すると、与えられたコミットのいずれかから到達可能なコミットのセットを意味します。

コミットの到達可能セットは、コミット自体とその祖先チェーン内のコミットです。

接続されたコミットのセット (「リビジョン範囲」と呼ばれる) を指定するためのいくつかの表記法があり、以下に示します。

コミットの除外

^<rev> (キャレット) 表記: コミットから到達可能なコミットを除外するには、プレフィックス ^ 表記を使用します。例えば、 ^r1 r2 は r2 から到達可能なコミットを意味しますが、 r1 から到達可能なもの (つまり r1 とその祖先) は除外します。

ドット範囲表記

.. (二点) 範囲表記: ^r1 r2 セット操作は非常に頻繁に現れるため、そのショートハンドが存在します。2つのコミット r1 と r2 (上記の「リビジョンの指定」で説明した構文に従って名前が付けられたもの) がある場合、 r2 から到達可能で、かつ r1 から到達可能なものを除外したコミットを ^r1 r2 で要求でき、これは r1..r2 と書くことができます。
... (三点) 対称差表記: 類似の表記法 r1...r2 は、 r1 と r2 の対称差と呼ばれ、 r1 r2 --not $(git merge-base --all r1 r2) と定義されます。これは、 r1 (左側) または r2 (右側) のいずれかから到達可能だが、両方からは到達可能でないコミットの集合です。

これらの2つの短縮表記では、片方の端を省略してHEADをデフォルトにすることができます。例えば、 origin.. は origin..HEAD の短縮形であり、「originブランチから分岐して以来、私は何をしたか？」と尋ねます。同様に、 ..origin は HEAD..origin の短縮形であり、「originは私から分岐して以来、何をしたか？」と尋ねます。 .. は HEAD..HEAD を意味し、HEADから到達可能でも到達不可能でもある空の範囲であることに注意してください。

2つの異なる範囲を取るように特別に設計されたコマンド (例えば、2つの範囲を比較する「git range-diff R1 R2」) は存在しますが、それらは例外です。特に明記されていない限り、コミットセットに対して操作を行うすべての「git」コマンドは、単一のリビジョン範囲で動作します。言い換えれば、2つの「2点範囲表記」を並べて書くことは、例えば、

$ git log A..B C..D

ほとんどのコマンドでは2つのリビジョン範囲を**指定しません**。代わりに、単一の接続されたコミットのセット、つまりBまたはDのいずれかから到達可能だが、AまたはCのどちらからも到達可能ではないコミットを名前で指定します。このような線形履歴では、

---A---B---o---o---C---D

AとBはCから到達可能であるため、これらの2つの点線範囲で指定されるリビジョン範囲は単一のコミットDです。

その他の <rev>^ 親の短縮表記

特にマージコミットに役立つ、コミットとその親コミットによって形成されるセットを命名するための3つの他の短縮形が存在します。

表記法 r1^@ は r1 のすべての親を意味します。

表記法 r1^! はコミット r1 を含みますが、そのすべての親を除外します。それ自体では、この表記法は単一のコミット r1 を示します。

表記法 <rev>^-[<n>] は <rev> を含みますが、<n>番目の親を除外します (つまり、 <rev>^<n>..<rev> の短縮形であり、<n>が指定されていない場合は1です)。これは通常、マージコミットにおいて、マージコミット <commit> にマージされたブランチ内のすべてのコミット ( <commit> 自体を含む) を取得するために <commit>^- を渡すだけでよい場合に便利です。

<rev>^<n> が単一のコミット親を指定することであったのに対し、これら3つの表記法はその親も考慮します。例えば、 HEAD^2^@ と言うことはできますが、 HEAD^@^2 と言うことはできません。

リビジョン範囲の概要

<rev>: <rev>から到達可能なコミット (つまり、<rev>とその祖先) を含めます。
^<rev>: <rev> から到達可能なコミット (つまり <rev> とその祖先) を除外します。
<rev1>..<rev2>: <rev2> から到達可能なコミットを含めますが、<rev1> から到達可能なコミットを除外します。<rev1> または <rev2> のいずれかが省略された場合、デフォルトで HEAD になります。
<rev1>...<rev2>: <rev1> または <rev2> のいずれかから到達可能なコミットを含めますが、両方から到達可能なコミットを除外します。<rev1> または <rev2> のいずれかが省略された場合、デフォルトで HEAD になります。
<rev>^@, 例: HEAD^@: アットマークが続くサフィックス ^ は、 <rev> のすべての親をリストするのと同じです (つまり、その親から到達可能なものはすべて含みますが、コミット自体は含みません)。
<rev>^!, 例: HEAD^!: 感嘆符が続くサフィックス ^ は、コミット <rev> とそのすべての親を ^ でプレフィックスして除外する (およびそれらの祖先も除外する) のと同じです。
<rev>^-<n>, 例: HEAD^-, HEAD^-2: <rev>^<n>..<rev> と同等であり、<n> が指定されていない場合は1です。

上記Loeligerの図を使用したいくつかの例を挙げます。表記法の展開と選択の各ステップを丁寧に説明します。

   Args   Expanded arguments    Selected commits
   D                            G H D
   D F                          G H I J D F
   ^G D                         H D
   ^D B                         E I J F B
   ^D B C                       E I J F B C
   C                            I J F C
   B..C   = ^B C                C
   B...C  = B ^F C              G H D E B C
   B^-    = B^..B
	  = ^B^1 B              E I J F B
   C^@    = C^1
	  = F                   I J F
   B^@    = B^1 B^2 B^3
	  = D E F               D G H E F I J
   C^!    = C ^C^@
	  = C ^C^1
	  = C ^F                C
   B^!    = B ^B^@
	  = B ^B^1 ^B^2 ^B^3
	  = B ^D ^E ^F          B
   F^! D  = F ^I ^J D           G H D F

PARSEOPT

--parseopt モードでは、git rev-parse は、Cの組み込み関数が持つのと同じ機能をシェルスクリプトにもたらすために、オプションを処理するのに役立ちます。getopt(1) が行うように、オプションの正規化 (例えば、単一のスイッチの集約値を分割する) のように機能します。

標準入力から解析して理解するオプションの仕様を受け取り、標準出力に sh(1) eval が引数を正規化されたものに置き換えるのに適した文字列を出力します。エラーが発生した場合、標準エラー出力ストリームに利用法を出力し、終了コード129で終了します。

注: 結果を eval に渡すときは、必ず引用符で囲んでください。例については以下を参照してください。

入力形式

git rev-parse --parseopt の入力形式は完全にテキストベースです。これは、 -- のみを含む行で区切られた2つの部分から構成されます。区切り文字より前の行 (1行以上である必要があります) は使用法に、区切り文字より後の行はオプションの説明に使用されます。

各オプション行は次の形式です。

<opt-spec><flags>*<arg-hint>? SP+ help LF

<opt-spec>

その形式は、短いオプション文字の後にカンマで区切られた長いオプション名です。両方の部分は必須ではありませんが、少なくとも一方は必要です。 <flags> 文字を含めることはできません。 h,help, dry-run, f は正しい <opt-spec> の例です。

<flags>

<flags> は *, =, ? または ! です。

オプションが引数を取る場合は = を使用します。
オプションが任意の引数を取ることを意味する場合は ? を使用します。オプションの引数を曖昧さなく解析できるように、おそらく --stuck-long モードを使用したいでしょう。
このオプションが -h 引数に対して生成される使用法にリストされないようにするには * を使用します。 gitcli[7] に記載されているように --help-all に表示されます。
対応する否定されたロングオプションを利用不可にするには ! を使用します。

<arg-hint>

引数を取るオプションの場合、 <arg-hint> が指定されていれば、ヘルプ出力で引数の名前として使用されます。 <arg-hint> は最初の空白で終了します。複数の単語からなる引数ヒントでは、単語をダッシュで区切るのが慣習です。

行の残りの部分 (スペースを除去した後) は、オプションに関連付けられたヘルプとして使用されます。

空行は無視され、この仕様に一致しない行はオプショングループヘッダーとして使用されます (意図的にそのような行を作成するには、行をスペースで始めます)。

例

OPTS_SPEC="\
some-command [<options>] <args>...

some-command does foo and bar!
--
h,help!   show the help

foo       some nifty option --foo
bar=      some cool option --bar with an argument
baz=arg   another cool option --baz with a named argument
qux?path  qux may take a path argument but has meaning by itself

  An option group Header
C?        option C with an optional argument"

eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

使用法テキスト

上記の例で "$@" が -h または --help の場合、以下の使用法テキストが表示されます。

usage: some-command [<options>] <args>...

    some-command does foo and bar!

    -h, --help            show the help
    --[no-]foo            some nifty option --foo
    --[no-]bar ...        some cool option --bar with an argument
    --[no-]baz <arg>      another cool option --baz with a named argument
    --[no-]qux[=<path>]   qux may take a path argument but has meaning by itself

An option group Header
    -C[...]               option C with an optional argument

SQ-QUOTE

--sq-quote モードでは、git rev-parse は標準出力に sh(1) eval に適した1行を出力します。この行は、 --sq-quote に続く引数を正規化することで作成されます。引数を引用符で囲む以外、何も行われません。

出力がシェルで引用符で囲まれる前に、コマンド入力が git rev-parse によって通常通り解釈されるようにしたい場合は、 --sq オプションを参照してください。

例

$ cat >your-git-script.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
command="git frotz -n24 $args"          # and use it inside a handcrafted
					# command line
eval "$command"
EOF

$ sh your-git-script.sh "a b'c"

例

現在のコミットのオブジェクト名を出力します。
```
$ git rev-parse --verify HEAD
```
$REVシェル変数内のリビジョンからコミットオブジェクト名を出力します。
```
$ git rev-parse --verify --end-of-options $REV^{commit}
```
$REVが空または有効なリビジョンでない場合、これはエラーになります。
上記と同様に、
```
$ git rev-parse --default master --verify --end-of-options $REV
```
ただし、$REVが空の場合、masterからのコミットオブジェクト名が出力されます。

git[1]スイートの一部

セットアップと設定

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

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

ブランチとマージ

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

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

配管コマンド

名前

概要

説明