Git

git-rev-parse は 2.45.3 で最終更新

NAME

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

SYNOPSIS

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

DESCRIPTION

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

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

OPTIONS

操作モード

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

--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つのパラメーターが提供され、それがオブジェクトデータベースにアクセスするために使用できる生形式の20バイトSHA-1に変換できることを確認します。もしそうであれば、それを標準出力に出力します。そうでなければ、エラーを出力して終了します。

出力が実際にオブジェクトデータベース内のオブジェクトを指定していること、および/または必要な特定のタイプのオブジェクトとして使用できることを確認したい場合、パラメーターに ^{type} ピーリング演算子を追加できます。たとえば、git rev-parse "$VAR^{commit}" は $VAR がコミットish（つまり、コミット、またはコミットを指す注釈付きタグ）である既存のオブジェクトを指定することを確認します。$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=<pattern>: シェルグロブパターン pattern に一致するすべての参照を表示します。パターンが refs/ で始まらない場合、自動的に前置されます。パターンにグロビング文字 (?, *, または [) が含まれていない場合、それは /* を追加することでプレフィックスマッチに変換されます。
--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

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

MERGE_HEAD

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

REBASE_HEAD

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

REVERT_HEAD

git 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}

現在のブランチのreflogエントリを取得するために、ref部分が空の @ 構造を使用できます。例えば、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> がコミットishの場合、<rev>^{commit} は対応するコミットオブジェクトを記述します。同様に、<rev> がツリーishの場合、<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 とその祖先) を除外したコミットを意味します。

ドット範囲表記

.. (2ドット) 範囲表記: ^r1 r2 のセット操作は非常によく使用されるため、その短縮形があります。上記「リビジョンの指定」で説明されている構文に従って命名された2つのコミット r1 と r2 がある場合、r2 から到達可能で、かつ r1 から到達可能なものを除くコミットを ^r1 r2 で要求でき、これは r1..r2 と書くことができます。
... (3ドット) 対称差表記: 同様の表記 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からフォークして以来、originは何をしたか？」を尋ねます。.. は HEAD..HEAD を意味し、これはHEADから到達可能かつ到達不可能な空の範囲であることに注意してください。

2つの異なる範囲を受け取るように特別に設計されたコマンド（例：「git range-diff R1 R2」で2つの範囲を比較する）は存在しますが、それらは例外です。特に明記されていない限り、コミットセットに対して操作するすべての「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>

その形式は、短いオプション文字、その後にコンマで区切られた長いオプション名です。両方の部分は必須ではありませんが、少なくとも1つは必要です。<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 に適した単一行を標準出力に出力します。この行は、--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] スイートの一部

セットアップと設定

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

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

ブランチとマージ

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

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

配管コマンド