設定と構成
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ
デバッグ
メール
外部システム
サーバー管理
- 2.46.1 → 2.47.0 変更なし
-
2.46.0
07/29/24
- 2.45.1 → 2.45.2 変更なし
-
2.45.0
04/29/24
- 2.44.1 → 2.44.2 変更なし
-
2.44.0
02/23/24
- 2.43.1 → 2.43.5 変更なし
-
2.43.0
11/20/23
- 2.42.1 → 2.42.3 変更なし
-
2.42.0
08/21/23
- 2.41.1 → 2.41.2 変更なし
-
2.41.0
06/01/23
- 2.39.4 → 2.40.3 変更なし
-
2.39.3
04/17/23
- 2.39.1 → 2.39.2 変更なし
-
2.39.0
12/12/22
- 2.37.3 → 2.38.5 変更なし
-
2.37.2
08/11/22
- 2.33.1 → 2.37.1 変更なし
-
2.33.0
08/16/21
- 2.31.1 → 2.32.7 変更なし
-
2.31.0
03/15/21
- 2.30.1 → 2.30.9 変更なし
-
2.30.0
12/27/20
- 2.29.1 → 2.29.3 変更なし
-
2.29.0
10/19/20
- 2.27.1 → 2.28.1 変更なし
-
2.27.0
06/01/20
- 2.25.1 → 2.26.3 変更なし
-
2.25.0
01/13/20
- 2.23.1 → 2.24.4 変更なし
-
2.23.0
08/16/19
- 2.22.1 → 2.22.5 変更なし
-
2.22.0
06/07/19
- 2.19.1 → 2.21.4 変更なし
-
2.19.0
09/10/18
- 2.18.1 → 2.18.5 変更なし
-
2.18.0
06/21/18
- 2.17.0 → 2.17.6 変更なし
-
2.16.6
12/06/19
-
2.15.4
12/06/19
- 2.14.6 変更なし
-
2.13.7
05/22/18
-
2.12.5
09/22/17
-
2.11.4
09/22/17
-
2.10.5
09/22/17
-
2.9.5
07/30/17
-
2.8.6
07/30/17
- 2.6.7 → 2.7.6 変更なし
-
2.5.6
05/05/17
-
2.4.12
05/05/17
- 2.3.10 変更なし
-
2.2.3
09/04/15
-
2.1.4
12/17/14
-
2.0.5
12/17/14
DESCRIPTION
多くのGitポーセリンコマンドは、フラグ(つまり、ダッシュ `-` で始まるパラメータ)と、内部的に使用する基盤となる `git rev-list` コマンド用のパラメータ、および `git rev-list` の下流で使用する他のコマンド用のフラグとパラメータを混在して受け取ります。このコマンドの主な目的は、呼び出しプログラムがそれらを区別できるようにすることです。上記のように「コマンドラインオプションを解析するヘルプ」とは関係のない、いくつかの他の動作モードもあります。
特に指定がない限り、ほとんどのオプションと動作モードでは、Gitリポジトリ内、またはGitリポジトリの管理下にある作業ツリー内でこのコマンドを実行する必要があり、そうでない場合は致命的エラーが発生します。
OPTIONS
出力のオプション
- --default <arg>
-
ユーザーからパラメータが指定されていない場合、代わりに `
` を使用します。 - --prefix <arg>
-
`git rev-parse` が作業ツリーの `
` サブディレクトリから呼び出されたかのように動作します。相対ファイル名は ` ` で接頭辞が付いているかのように解決され、その形式で出力されます。 これは、サブディレクトリで実行されるコマンドの引数を、リポジトリのトップレベルに移動した後でも使用できるように変換するために使用できます。例えば
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` が既存のオブジェクトで、コミットイッシュ(つまり、コミット、またはコミットを指す注釈付きタグ)であることを確認します。`$VAR` が任意の種類の既存のオブジェクトを指名することを確認するには、`git rev-parse "$VAR^{object}"` を使用できます。
信頼できないソースからの名前を検証する場合は、名前引数が別のオプションと間違われないように `--end-of-options` を使用することをお勧めします。
- -q
- --quiet
-
`--verify` モードでのみ意味を持ちます。最初の引数が有効なオブジェクト名でない場合、エラーメッセージを出力せず、代わりにゼロ以外のステータスでサイレントに終了します。有効なオブジェクト名のSHA-1は、成功時に標準出力に出力されます。
- --sq
-
通常、出力はフラグとパラメータごとに1行になります。このオプションは、シェルで消費するために適切に引用された単一行の出力を生成します。パラメータに空白と改行が含まれていると予想される場合(例:`git diff-*` でピッケル `-S` を使用する場合)に役立ちます。`--sq-quote` オプションとは対照的に、コマンド入力は通常どおり解釈されます。
- --short[=<length>]
-
`--verify` と同じですが、オブジェクト名を少なくとも `
` 文字の一意のプレフィックスに短縮します。最小長は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/` 内に見つかったすべてのrefを表示します。
- --branches[=<pattern>]
- --tags[=<pattern>]
- --remotes[=<pattern>]
-
それぞれ、すべてのブランチ、タグ、またはリモートトラッキングブランチを表示します(つまり、それぞれ `refs/heads`、`refs/tags`、または `refs/remotes` 内に見つかったref)。
`pattern` が指定されている場合、指定されたシェルglobと一致するrefのみが表示されます。パターンにグロビング文字(`?`、`*`、または `[`)が含まれていない場合、`/*` を追加することでプレフィックスマッチに変換されます。
- --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/
で始める必要があります。末尾の/*を意図している場合、明示的に指定する必要があります。 -
適切な
fetch.hideRefs
、receive.hideRefs
、またはuploadpack.hideRefs
設定とtransfer.hideRefs
を参照することにより、git-fetch
、git-receive-pack
、またはgit-upload-pack
によって非表示になる参照を含めないでください(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>が有効なリポジトリであるか、有効なリポジトリを指すgitファイルであるかどうかをチェックし、リポジトリの場所を出力します。<path>がgitファイルの場合、実際のレポジトリへの解決されたパスが出力されます。
- --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
-
現在のリポジトリをサブモジュールとして使用するスーパープロジェクトの作業ツリーのルートの絶対パス(存在する場合)を表示します。現在のリポジトリがどのプロジェクトでもサブモジュールとして使用されていない場合は、何も出力しません。
-
分割インデックスモードでの共有インデックスファイルへのパスを表示します。分割インデックスモードでない場合は空です。
以下のオプションは--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
-
リポジトリで使用されている参照ストレージ形式を表示します。
リビジョンの指定
リビジョンパラメータ<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の両方を持っている場合、heads/masterを明示的に指定して、どちらを意味するかをGitに伝えることができます。曖昧な場合、<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
ファイルのどちらから取得される可能性があります。 ref名のエンコーディングは指定されていませんが、一部の出力処理ではref名がUTF-8であると仮定するため、UTF-8が推奨されます。 -
- @
-
@だけでは
HEAD
のショートカットです。 - [<refname>]@{<date>}、例:master@{yesterday}、HEAD@{5 minutes ago}
-
refの後に、中括弧で囲まれた日付の指定(例:{yesterday}、{1 month 2 weeks 3 days 1 hour 1 second ago}、または{1979-02-26 18:30:00})を伴う@サフィックスを付けることで、過去のある時点におけるrefの値を指定します。このサフィックスはref名の直後にのみ使用でき、refには既存のログ($GIT_DIR/logs/<ref>)が必要です。これは、特定の時点における**ローカル**refの状態(例:先週のローカルのmasterブランチの内容)を検索することに注意してください。特定の時間に作成されたコミットを確認したい場合は、
--since
と--until
を参照してください。 - <refname>@{<n>}、例:master@{1}
-
refの後に、中括弧で囲まれた序数指定(例:{1}、{15})を伴う@サフィックスを付けることで、そのrefのn番目の前の値を指定します。たとえば、master@{1}はmasterの直前の値であり、master@{5}はmasterの5番目の前の値です。このサフィックスはref名の直後にのみ使用でき、refには既存のログ($GIT_DIR/logs/<refname>)が必要です。
- @{<n>}、例:@{1}
-
空のref部分を伴う@構文を使用して、現在のブランチのreflogエントリを取得できます。たとえば、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
がチェックアウトされている間にgit push
を実行した場合の「プッシュ先のブランチ」(branchnameが指定されていない場合は現在のHEAD
)を報告します。@{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
この例では、1つの場所からプルし、別の場所にプッシュする三角形のワークフローを設定していることに注意してください。三角形ではないワークフローでは、@{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>がタグである必要がなく、<rev>を参照解除する必要がないため、<rev>が存在するオブジェクトであることを確認するために<rev>^{object}を使用できます。タグはすでにオブジェクトであるため、オブジェクトを取得するために一度も参照解除する必要はありません。
<rev>が存在するタグオブジェクトを識別するために、<rev>^{tag}を使用できます。
- <rev>^{}、例:v0.99.8^{}
-
空の中括弧を伴う^サフィックスは、オブジェクトがタグである可能性があり、非タグオブジェクトが見つかるまでタグを再帰的に参照解除することを意味します。
- <rev>^{/<text>}、例:HEAD^{/fix nasty bug}
-
リビジョンパラメータへの^サフィックスの後に、スラッシュで始まるテキストを含む中括弧を付けることは、以下の:/fix nasty bug構文と同じですが、^の前にある<rev>から到達可能な、最も若い一致するコミットを返します。
- :/<text>、例::/fix nasty bug
-
コロン、スラッシュ、テキストの後に、コミットメッセージが指定された正規表現と一致するコミットを指定します。この名前は、HEADを含むすべてのrefから到達可能な、最も若い一致するコミットを返します。正規表現はコミットメッセージの任意の部分と一致できます。文字列で始まるメッセージと一致させるには、例として:/^fooを使用できます。特別なシーケンス:/!は、一致するものの修飾子として予約されています。:/!-fooは否定的な一致を実行し、:/!!fooはリテラルの!文字の後にfooが続くものと一致します。:/!で始まるその他のシーケンスは、現時点では予約されています。指定されたテキストによっては、シェルの単語分割ルールで追加の引用が必要になる場合があります。
- <rev>:<path>、例:HEAD:README、master:./README
-
コロンの後にパスを付けるサフィックスは、コロンの前にある部分で名前が付けられたツリーのようなオブジェクト内の指定されたパスにあるblobまたはツリーを指定します。./または../で始まるパスは、現在の作業ディレクトリを基準とした相対パスです。指定されたパスは、作業ツリーのルートディレクトリを基準とした相対パスに変換されます。これは、作業ツリーと同じツリー構造を持つコミットまたはツリーからblobまたはツリーにアクセスする場合に最も役立ちます。
- :[<n>:]<path>、例::0:README、:README
-
コロンの後に、オプションでステージ番号(0〜3)とコロンを付け、パスの後に、インデックス内の指定されたパスにあるblobオブジェクトを指定します。ステージ番号(およびそれに続くコロン)がない場合は、ステージ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
などの履歴トラバースコマンドは、単一のコミットではなく、コミットのセットに対して動作します。
これらのコマンドの場合、前のセクションで説明した表記を使用して単一のrevisionを指定することは、指定されたコミットから「到達可能」なコミットのセットを意味します。
複数のrevisionを指定することは、指定されたコミットのいずれかから到達可能なコミットのセットを意味します。
コミットの到達可能なセットとは、コミット自体とその先祖チェーン内のコミットです。
接続されたコミットのセット(「revision range」と呼ばれる)を指定するためのいくつかの表記があり、以下に示します。
点付き範囲表記
- ..(2点)範囲表記
-
^r1 r2集合演算は非常に頻繁に表示されるため、省略形があります。2つのコミットr1とr2(上記のREVISIONの指定で説明されている構文に従って命名)がある場合、^r1 r2によって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は何をしましたか?」という質問をします。..はHEAD..HEADを意味し、HEADから到達可能であり、到達不可能でもある空の範囲であることに注意してください。
2つの異なる範囲を具体的に取るように設計されたコマンド(例:「git range-diff R1 R2」で2つの範囲を比較する)は存在しますが、例外です。特に明記されていない限り、コミットのセットに対して動作するすべての「git」コマンドは、単一のrevision rangeに対して動作します。言い換えれば、2つの「2点範囲表記」を互いに並べて記述するなど
$ git log A..B C..D
ほとんどのコマンドでは、**2つのrevision range**を指定しません。代わりに、BまたはDから到達可能であるが、AまたはCから到達可能ではない、単一の接続されたコミットのセットを指定します。このような線形履歴では
---A---B---o---o---C---D
AとBはCから到達可能であるため、これらの2つの点付き範囲で指定されたrevision rangeは単一のコミットDです。
その他の<rev>^ 親省略表記
マージコミットに特に有用な、コミットとその親コミットによって形成される集合を命名するための、3つの省略表記が存在します。
r1^@表記は、r1のすべての親を意味します。
r1^!表記にはコミットr1が含まれますが、そのすべての親は除外されます。単独で使用する場合、この表記は単一のコミットr1を表します。
<rev>^-[<n>]表記には<rev>が含まれますが、<n>番目の親を除外します(つまり、<rev>^<n>..<rev>の省略表記です)。<n>が指定されていない場合は<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>が指定されていない場合は<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
オプションを参照してください。
例
-
現在のコミットのオブジェクト名を出力します。
$ 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
git[1]スイートの一部