SYNOPSIS
gitrevisions
DESCRIPTION
多くのGitコマンドは、リビジョンパラメーターを引数として取ります。コマンドに応じて、特定のコミットを示します。リビジョングラフをたどるコマンド(git-log(1) など)の場合は、そのコミットから到達可能なすべてのコミットを示します。リビジョングラフをたどるコマンドの場合、リビジョンの範囲を明示的に指定することもできます。
さらに、一部のGitコマンド(git-show(1) や git-push(1) など)は、コミット以外のオブジェクトを示すリビジョンパラメーターを受け取ることもできます。例えば、ブロブ(ファイル)またはツリー(ファイルのディレクトリ)です。
SPECIFYING REVISIONS
リビジョンパラメータ <rev> は必ずしもそうとは限りませんが、通常はコミットオブジェクトに名前を付けます。これは、いわゆる「拡張SHA-1」構文を使用します。 オブジェクト名を綴るにはさまざまな方法があります。このリストの終わり近くにリストされているものは、コミットに含まれているツリーとブロブに名前を付けています。
|
Note
|
この文書は、gitで見られる「生の」構文を示しています。シェルおよびその他のUIでは、特殊文字を保護し、単語の分割を回避するために、追加の引用符が必要になる場合があります。 |
-
<sha1> 例:
dae86e1950b1277e545cee180551750029cfe735,dae86e -
完全なSHA-1オブジェクト名(40バイトの16進文字列)、またはリポジトリ内で一意の先頭のsubstring。例えば dae86e1950b1277e545cee180551750029cfe735 と dae86e はどちらも、リポジトリ内にオブジェクト名が dae86e で始まる他のオブジェクトがない場合、全く同じコミットオブジェクトに名前を付けます。
-
<describeOutput> 例:
v1.7.4.2-679-g3bee7fb -
gitdescribeからの出力。つまり、現在のコミットから最も近いタグ。オプションで、ダッシュ(-)とそのタグ以降現在のコミットが何番目になるかの数が続き、その後にダッシュ(-)、「g」、および省略されたオブジェクト名が続きます。 -
<refname> 例:
master,heads/master,refs/heads/master -
シンボリックref名。例えば
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 -
最後の
gitfetch呼び出しでリモート・リポジトリからフェッチしたブランチを記録しています。 -
ORIG_HEAD -
これは、
HEADを大幅に動かすコマンド (gitam、gitmerge、gitrebase、gitreplace) によって作成され、 これらのコマンド操作前のHEADの位置を記録します。 ブランチの先端を実行前の状態に簡単に戻すことができます。 -
MERGE_HEAD -
gitmergeを実行するときにブランチにマージするコミットを記録しています。 -
REBASE_HEAD -
リベース中、 競合または対話型リベースの
editコマンドにより、現在操作が停止(stop)しているコミットを記録しています。 -
REVERT_HEAD -
gitrevertを実行したときに元に戻すコミットを記録します。 -
CHERRY_PICK_HEAD -
gitCherry-pickを実行するときにチェリーピッキングしているコミットを記録します。 -
BISECT_HEAD -
gitbisect--no-checkoutの実行中、現在テスト対象のコミットを記録しています。 -
AUTO_MERGE -
マージ操作で競合が発生した場合に、 「ort」マージ戦略が作業ツリーに書き込んだ状態に対応する、 ツリー・オブジェクトを記録します。
注意: 上記の
refs/* の場合、$GIT_DIR/refsディレクトリまたは$GIT_DIR/packed-refsファイルのいずれかから発生する可能性があることに注意してください。ref名のエンコードは指定されていませんが、一部の出力処理ではUTF-8でref名を想定する場合があるため、UTF-8が推奨されます。 -
-
@ -
@単独ではHEADのショートカットを意味します。 -
[<refname>]
@{<date>} 例:master@{yesterday},HEAD@{5minutesago} -
refの後に接尾辞
@が続き、日付指定が中括弧のペアで囲まれています(例: {yesterday} 、 {1month2weeks3days1hour1secondago} 、{1979-02-2618: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がチェックアウトされているときにgitpushが実行された場合(またはブランチ名が指定されていない場合は現在の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注意: この例では、ある場所からプルして別の場所にプッシュする三角形のワークフローを設定していることに注意してください。非三角形のワークフローでは、
@{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} -
接尾辞
^の後に中括弧のペアで囲まれたオブジェクトタイプ名が続くということは、タイプ <type> のオブジェクトが見つかるか、オブジェクトを逆参照できなくなるまで、 <rev> でオブジェクトを再帰的に逆参照する(この場合は、いろいろ一旦飲み込んでしまったのを吐きもどすような感じだぬ)ことを意味します。 たとえば、 <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^{/fixnastybug} -
リビジョンパラメータの接尾辞
^と、それに続くスラッシュで始まるテキストを含む中括弧のペアは、以下の:/fixnastybug構文と同じですが、^の前の <rev> から到達可能な一致する最も若いコミットを返す点が異なります。 -
:/<text> 例::/fixnastybug -
コロンに続いてスラッシュそしてそれに続くテキストは、コミットメッセージが指定された正規表現と一致するコミットを示します。この名前は、HEADを含む任意のrefから到達可能な最も若い一致するコミットを返します。正規表現は、コミットメッセージの任意の部分に一致できます。文字列で始まるメッセージを照合するには、たとえば、
:/^fooとします。特別なシーケンス:/! はマッチングの修飾子用に予約されています。ます。:/!-foo は一致の否定を実行し、:/!!foo はリテラル ! 後にfooが続く文字列とマッチします。:/! で始まるその他のシーケンスは今のところ予約されています。指定されたテキストによっては、シェルにより追加の引用符が必要になる場合があります。 -
<rev>
:<path> 例:HEAD:README,master:./README -
接尾辞
:の後にパス(path)を続けると、コロンの前の部分によって名前が付けられたツリー風のオブジェクト内の、指定されたパスにあるブロブまたはツリーに名前が付けられます。./または../で始まるパスは、現在の作業ディレクトリからの相対パスです。指定のパスは、作業ツリーのルートディレクトリからの相対パスに変換されます。これは、作業ツリーと同じツリー構造を持つコミットまたはツリーからブロブまたはツリーをアドレス指定するのに最も役立ちます。 -
:[<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
SPECIFYING RANGES
git log などの履歴トラバースコマンドは、単一のコミットだけでなく、一連のコミットで動作します。
これらのコマンドの場合、前のセクションで説明した表記法を使用して単一のリビジョンを指定することは、指定のコミットから「到達可能」なコミットの組を意味します。
複数のリビジョンを指定するということは、指定のコミットのいずれかから到達可能なコミットの組を意味します。
コミットの到達可能な組は、コミット自体とその祖先チェーン内のコミットです。
以下に示すように、接続されたコミット(connected commits)の組(「リビジョン範囲」(revision range)と呼ばれる)を指定するためのいくつかの表記法があります。
Commit Exclusions
-
^<rev> (カレット)記法 -
とある到達可能なコミットをコミット達から除外するには、接頭辞
^表記を使用します。 例えば^r1r2はr2から到達可能なコミットだけども、r1から到達可能なコミット(つまりr1とその祖先)は除外する事を意味します。
Dotted Range Notations
- .. (2ドット)範囲記法
-
^r1r2操作は頻繁に表示されるため、省略形があります。(上記の SPECIFYING REVISIONS で説明されている構文に従って名前が付けられている)2つのコミットr1とr2がある場合、あなたは^r1r2によってr1から到達可能なコミットを取り除き、r2から到達可能なコミットを要求できます。そしてこれはr1..r2と書くことができます。 - ... (3ドット)対称差記法
-
似た表記
r1...r2はr1とr2の対称差と呼ばれ、r1r2--not$(gitmerge-base--allr1r2) として定義されます。 これは、r1(左側)またはr2(右側)のいずれかから到達可能であるが、両方からは到達できないコミットの組です。
これらの2つの省略表記では、一方の端を省略して、デフォルトでHEADにすることができます。たとえば、 origin.. は origin..HEAD の省略形であり、「originブランチから分岐(fork)してから何をしましたか?」と尋ねます。 同様に、 ..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つの2ドット範囲記法で指定されたリビジョン範囲は単一のコミットDです。
Other <rev>^ Parent Shorthand Notations
コミットとその親コミットによって形成される組に名前を付けるために、マージコミットに特に役立つ他の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 と言うことはできません。
Revision Range Summary
- <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
SEE ALSO
GIT
Part of the git(1) suite