gitrevisions - Specifying revisions and ranges for Gitgitrevisions - Gitのリビジョンと範囲の指定




Many Git commands take revision parameters as arguments. Depending on the command, they denote a specific commit or, for commands which walk the revision graph (such as git-log[1]), all commits which are reachable from that commit. For commands that walk the revision graph one can also specify a range of revisions explicitly.多くのGitコマンドは引数としてリビジョンパラメータを取ります。コマンドに応じて、それらは特定のコミット、またはリビジョングラフをたどるコマンド(git-log [1]など)の場合、そのコミットから到達可能なすべてのコミットを示します。リビジョングラフをたどるコマンドでは、リビジョンの範囲を明示的に指定することもできます。

In addition, some Git commands (such as git-show[1] and git-push[1]) can also take revision parameters which denote other objects than commits, e.g. blobs ("files") or trees ("directories of files").さらに、いくつかのGitコマンド(git-show [1]git-push [1]など)は、コミット以外のオブジェクトを示すリビジョンパラメータを取ることもできます。例えば、blob( "files")やtrees( "files of directories") )


A revision parameter <rev> typically, but not necessarily, names a commit object. It uses what is called an extended SHA-1 syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit.リビジョンパラメータ<rev>は通常、必ずというわけではありませんが、コミットオブジェクトを指定します。これは、いわゆる拡張SHA-1構文を使用しています。これはオブジェクト名をつづる様々な方法です。このリストの末尾近くにリストされているものは、コミットに含まれるツリーとBLOBに名前を付けます。

Note This document shows the "raw" syntax as seen by git. The shell and other UIs might require additional quoting to protect special characters and to avoid word splitting. この文書はgitから見た「生の」構文を示しています。シェルや他のUIでは、特殊文字を保護し単語の分割を避けるために追加の引用符が必要になる場合があります。
<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e <sha1>、例:dae86e1950b1277e545cee180551750029cfe735dae86e

The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within the repository. E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit object if there is no other object in your repository whose object name starts with dae86e.完全なSHA-1オブジェクト名(40バイトの16進数ストリング)、またはリポジトリー内で固有の先行サブストリング。たとえば、dae86e1950b1277e545cee180551750029cfe735とdae86eは、オブジェクト名がdae86eで始まる他のオブジェクトがリポジトリにない場合、どちらも同じコミットオブジェクトを指定します。

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

Output from git describe; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a g, and an abbreviated object name.からの出力git describe。つまり、最も近いタグ、オプションでダッシュとコミット数、ダッシュ、g、および省略形のオブジェクト名が続きます。

<refname>, e.g. master, heads/master, refs/heads/master <refname>、例えばmasterheads / masterrefs / heads / master

A symbolic ref name. E.g. master typically means the commit object referenced by refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell Git which one you mean. When ambiguous, a <refname> is disambiguated by taking the first match in the following rules:シンボリック参照名 例えばmasterは通常refs / heads / masterによって参照されるコミットオブジェクトを意味します。あなたは両方持ってしまった場合、ヘッド/マスタータグ/マスターを、明示的に言うことができるヘッド/マスターあなたが意味どちらのGitを伝えるために。あいまいな場合、<refname>は次の規則の最初の一致を取ることによって曖昧さがなくなります。

  1. If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD);場合は$ GIT_DIR / <もしrefname>が存在している、それはあなたが(これはのみのために、通常は有益であることを意味するものであるHEADFETCH_HEADORIG_HEADMERGE_HEADおよびCHERRY_PICK_HEAD)。

  2. otherwise, refs/<refname> if it exists;それ以外の場合は、存在する場合は/ <refname>を参照します。

  3. otherwise, refs/tags/<refname> if it exists;そうでなければ、/ tags / <refname>があればそれを参照します。

  4. otherwise, refs/heads/<refname> if it exists;それ以外の場合は、存在する場合は/ head / <refname>を参照します。

  5. otherwise, refs/remotes/<refname> if it exists;それ以外の場合は、存在する場合は/ remotes / <refname>を参照します。

  6. otherwise, refs/remotes/<refname>/HEAD if it exists.それ以外の場合は、存在する場合は/ remotes / <refname> / HEADを参照します。

    HEAD names the commit on which you based the changes in the working tree. FETCH_HEAD records the branch which you fetched from a remote repository with your last git fetch invocation. ORIG_HEAD is created by commands that move your HEAD in a drastic way, to record the position of the HEAD before their operation, so that you can easily change the tip of the branch back to the state before you ran them. MERGE_HEAD records the commit(s) which you are merging into your branch when you run git merge. CHERRY_PICK_HEAD records the commit which you are cherry-picking when you run git cherry-pick.HEAD作業ツリーの変更に基づいたコミットを指定します。FETCH_HEAD前回のgit fetch呼び出しでリモートリポジトリから取得したブランチを記録します。操作前の位置を記録するために劇的な方法でORIG_HEADあなたを動かすコマンドによって作成されるので、あなたはそれらを実行する前の状態にブランチの先端を簡単に戻すことができます。実行したときにブランチにマージしているコミットを記録します。実行したときにチェリーピッキングしているコミットを記録します。HEADHEADMERGE_HEADgit mergeCHERRY_PICK_HEADgit cherry-pick

    Note that any of the refs/* cases above may come either from the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file. While the ref name encoding is unspecified, UTF-8 is preferred as some output processing may assume ref names in UTF-8.上記のrefs / *のケースはすべて、$ GIT_DIR / refsディレクトリまたは$ GIT_DIR / packed-refsファイルのどちらからでも得られることに注意してください。参照名のエンコードは指定されていませんが、出力処理によっては参照名がUTF-8であると想定される可能性があるため、UTF-8が推奨されます。


@ alone is a shortcut for HEAD.@だけがショートカットですHEAD

<refname>@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago} <refname> @ {<date>}、例:master @ {昨日}HEAD @ {5分前}

A ref followed by the suffix @ with a date specification enclosed in a brace pair (e.g. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} or {1979-02-26 18:30:00}) specifies the value of the ref at a prior point in time. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state of your local ref at a given time; e.g., what was in your local master branch last week. If you want to look at commits made during certain times, see --since and --until.refに続けて、中かっこで囲まれた日付指定付きの接尾辞@(例:{昨日}{1ヶ月2週間3日1時間1秒前}または{1979-02-26 18:30:00})前の時点でのrefの値 この接尾辞は、参照名の直後にのみ使用でき、参照には既存のログが必要です($ GIT_DIR / logs / <ref>)。これは与えられた時間にあなたの地元の refの状態を調べることに注意してください。例えば、先週あなたの地元のマスターブランチにあったものなどです。あなたが特定の時間中に行われたコミットを見たい場合は、参照--sinceして--until

<refname>@{<n>}, e.g. master@{1} <refname> @ {<n>}、例master @ {1}

A ref followed by the suffix @ with an ordinal specification enclosed in a brace pair (e.g. {1}, {15}) specifies the n-th prior value of that ref. For example master@{1} is the immediate prior value of master while master@{5} is the 5th prior value of master. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/<refname>).refの後に、波括弧のペアで囲まれた序数指定を伴う接尾辞@が続くもの(例:{1}{15})は、そのrefのn番目の前の値を指定します。例えば、マスター@ {1}の直前の値であるマスタながらマスター@は{5}の5日前の値であるマスタ。この接尾辞は、参照名の直後にのみ使用でき、参照には既存のログが必要です($ GIT_DIR / logs / <refname>)。

@{<n>}, e.g. @{1} @ {<n>}、例えば@ {1}

You can use the @ construct with an empty ref part to get at a reflog entry of the current branch. For example, if you are on branch blabla then @{1} means the same as blabla@{1}.現在のブランチのreflogエントリを取得するには、空のref部分を指定して@構文を使用します。たとえば、blablaブランチにいる場合@ {1}blabla @ {1}と同じ意味です。

@{-<n>}, e.g. @{-1} @ { - <n>}、例えば@ { - 1}

The construct @{-<n>} means the <n>th branch/commit checked out before the current one.コンストラクト@ { - <n>}は、現在のブランチの前にチェックアウトされたn番目のブランチ/コミットを意味します。

<branchname>@{upstream}, e.g. master@{upstream}, @{u} <branchname> @ {upstream}、例:master @ {upstream}@ {u}

The suffix @{upstream} to a branchname (short form <branchname>@{u}) refers to the branch that the branch specified by branchname is set to build on top of (configured with branch.<name>.remote and branch.<name>.merge). A missing branchname defaults to the current one. These suffixes are also accepted when spelled in uppercase, and they mean the same thing no matter the case.支店名の接尾辞@ {upstream}(省略形<branchname> @ {u})は、branchnameで指定された支店が(branch.<name>.remoteandで構成された)上に構築するように設定されている支店を表しますbranch.<name>.merge。不足している支店名は、デフォルトで現在のものになります。これらの接尾辞は大文字でつづられるときも受け入れられます、そして、それらは大文字小文字を問わず同じことを意味します。

<branchname>@{push}, e.g. master@{push}, @{push} <branchname> @ {push}、例えばmaster @ {push}@ {push}

The suffix @{push} reports the branch "where we would push to" if git push were run while branchname was checked out (or the current HEAD if no branchname is specified). Since our push destination is in a remote repository, of course, we report the local tracking branch that corresponds to that branch (i.e., something in refs/remotes/).接尾辞@ {push}は、チェックアウトされているgit pushbranchnameに実行HEADされた場合(または、分岐名が指定されていない場合は現在の)、分岐先「プッシュ先」を報告します。プッシュ先はリモートリポジトリにあるので、もちろん、そのブランチに対応するローカルトラッキングブランチを報告します(すなわち、refs / remotes /の中の何か)。

Here’s an example to make it more clear:これを明確にするための例を示します。

$ git config push.default current
$ git config remote.pushdefault myfork
$ git checkout -b mybranch origin/master
$ git rev-parse --symbolic-full-name @{upstream}
$ git rev-parse --symbolic-full-name @{push}

Note in the example that we set up a triangular workflow, where we pull from one location and push to another. In a non-triangular workflow, @{push} is the same as @{upstream}, and there is no need for it.この例では、ある場所からプルして別の場所にプッシュする三角形のワークフローを設定したことに注意してください。非三角形のワークフローでは、@ {push}@ {upstream}と同じであり、必要ありません。

This suffix is also accepted when spelled in uppercase, and means the same thing no matter the case.この接尾辞は大文字で綴られている場合にも受け入れられ、大文字小文字を問わず同じことを意味します。

<rev>^, e.g. HEAD^, v1.5.1^0 <rev> ^、例えばHEAD ^、v1.5.1 ^ 0

A suffix ^ to a revision parameter means the first parent of that commit object. ^<n> means the <n>th parent (i.e. <rev>^ is equivalent to <rev>^1). As a special rule, <rev>^0 means the commit itself and is used when <rev> is the object name of a tag object that refers to a commit object.リビジョンパラメータの接尾辞^は、そのコミットオブジェクトの最初の親を意味します。^ <n>はn番目の親を意味します(つまり、<rev> ^<rev> ^ 1と同じです)。特別な規則として、<rev> ^ 0はコミット自体を意味し、<rev>がコミットオブジェクトを参照するタグオブジェクトのオブジェクト名である場合に使用されます。

<rev>~<n>, e.g. master~3 <rev>〜<n>、例:master〜3

A suffix ~<n> to a revision parameter means the commit object that is the <n>th generation ancestor of the named commit object, following only the first parents. I.e. <rev>~3 is equivalent to <rev>^^^ which is equivalent to <rev>^1^1^1. See below for an illustration of the usage of this form.リビジョンパラメータの接尾辞〜<n>は、最初の親のみに続く、名前付きコミットオブジェクトの<n>世代の祖先であるコミットオブジェクトを意味します。すなわち<REV>〜3に相当します<REV> ^^^に相当する<REV> ^ 1 ^ 1 ^ 1。このフォームの使用方法については、以下を参照してください。

<rev>^{<type>}, e.g. v0.99.8^{commit} <rev> ^ {<type>}、例えばv0.99.8 ^ {commit}

A suffix ^ followed by an object type name enclosed in brace pair means dereference the object at <rev> recursively until an object of type <type> is found or the object cannot be dereferenced anymore (in which case, barf). For example, if <rev> is a commit-ish, <rev>^{commit} describes the corresponding commit object. Similarly, if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree object. <rev>^0 is a short-hand for <rev>^{commit}.サフィックス^ブレース対で囲まれたオブジェクトタイプ名が続くが、あるオブジェクトを間接参照を意味する<REV>再帰型のオブジェクトまで<タイプ>見出されるまたはオブジェクトが(その場合、BARFに)もはや間接参照することはできません。たとえば、<rev>がコミット風の場合、<rev> ^ {commit}は対応するコミットオブジェクトを表します。同様に、<rev>がツリー状の場合、<rev> ^ {tree}は対応するツリーオブジェクトを表します。<rev> ^ 0<rev> ^ {commit}の省略形です。

rev^{object} can be used to make sure rev names an object that exists, without requiring rev to be a tag, and without dereferencing rev; because a tag is already an object, it does not have to be dereferenced even once to get to an object.REV ^ {目的は}を確認するために使用することができるREVを必要とせず、名前存在するオブジェクトをREVをタグであること、及び間接参照せずに回転します。タグはすでにオブジェクトであるため、オブジェクトに到達するためにタグを1回でも参照解除する必要はありません。

rev^{tag} can be used to ensure that rev identifies an existing tag object.rev ^ {tag}は、revが既存のタグオブジェクトを識別するようにするために使用できます。

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

A suffix ^ followed by an empty brace pair means the object could be a tag, and dereference the tag recursively until a non-tag object is found.空の中括弧のペアが後に続く接尾辞^は、そのオブジェクトがタグである可能性があることを意味し、タグではないオブジェクトが見つかるまでタグを再帰的に参照解除します。

<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug} <rev> ^ {/ <text>}、例えばHEAD ^ {/厄介なバグを修正}

A suffix ^ to a revision parameter, followed by a brace pair that contains a text led by a slash, is the same as the :/fix nasty bug syntax below except that it returns the youngest matching commit which is reachable from the <rev> before ^.リビジョンパラメータの接尾辞^の後にスラッシュが付いたテキストを含む中括弧のペアは、<rev>から到達可能な最も若い一致コミットを返すことを除いて、以下の:/ fix厄介なバグ構文と同じです。前^

:/<text>, e.g. :/fix nasty bug :/ <テキスト>、例:/厄介なバグを修正

A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression. This name returns the youngest matching commit which is reachable from any ref, including HEAD. The regular expression can match any part of the commit message. To match messages starting with a string, one can use e.g. :/^foo. The special sequence :/! is reserved for modifiers to what is matched. :/!-foo performs a negative match, while :/!!foo matches a literal ! character, followed by foo. Any other sequence beginning with :/! is reserved for now. Depending on the given text, the shell’s word splitting rules might require additional quoting.コロン、それに続くスラッシュ、それに続くテキストは、コミットメッセージが指定された正規表現に一致するコミットを指定します。この名前は、HEADを含むどの参照からも到達可能な最も若いマッチングコミットを返します。正規表現はコミットメッセージのどの部分にも一致できます。文字列で始まるメッセージにマッチさせるためには、例えば:/ ^ fooを使うことができます。特別なシーケンス:/!一致するものに対する修飾子のために予約されています。:/! - fooは否定一致を実行しますが、:/ !! fooはリテラルに一致しますその後にfooが続きます。:/!で始まるその他のシーケンス今のところ予約されています。与えられたテキストによっては、シェルの単語分割規則で追加の引用符が必要になる場合があります。

<rev>:<path>, e.g. HEAD:README, :README, master:./README <rev>:<path>、例:HEAD:README:READMEmaster:./ README

A suffix : followed by a path names the blob or tree at the given path in the tree-ish object named by the part before the colon. :path (with an empty part before the colon) is a special case of the syntax described next: content recorded in the index at the given path. A path starting with ./ or ../ is relative to the current working directory. The given path will be converted to be relative to the working tree’s root directory. This is most useful to address a blob or tree from a commit or tree that has the same tree structure as the working tree.接尾辞:の後にパスを続けると、コロンの前の部分で指定されたツリー風のオブジェクト内の指定されたパスにあるBLOBまたはツリーを指定します。:path(コロンの前に空の部分がある)は、次に説明する構文の特殊なケースです。contentは、指定されたパスのインデックスに記録されます。./または../で始まるパスは、現在の作業ディレクトリからの相対パスです。与えられたパスは作業ツリーのルートディレクトリからの相対パスに変換されます。これは、作業ツリーと同じツリー構造を持つコミットまたはツリーからBLOBまたはツリーをアドレス指定するのに最も役立ちます。

:<n>:<path>, e.g. :0:README, :README :<n>:<path>、例:0:README:README

A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path, names a blob object in the index at the given path. A missing stage number (and the colon that follows it) names a stage 0 entry. During a merge, stage 1 is the common ancestor, stage 2 is the target branch’s version (typically the current branch), and stage 3 is the version from the branch which is being merged.コロンの後にステージ番号(0から3)、コロンの後にパスが続くと、インデックス内の指定されたパスのBLOBオブジェクトに名前が付けられます。欠落しているステージ番号(およびそれに続くコロン)は、ステージ0エントリーを指定します。マージ中、ステージ1は共通の先祖、ステージ2はターゲットブランチのバージョン(通常は現在のブランチ)、そしてステージ3はマージされているブランチのバージョンです。

Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.これはJon Loeligerによるイラストです。コミットノードBとCはどちらもコミットノードAの親です。親コミットは左から右に並べられます。

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
A =      = A^0
B = A^   = A^1     = A~1
C = A^2  = 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


History traversing commands such as git log operate on a set of commits, not just a single commit.git log単一のコミットだけでなく、一連のコミットを操作するなどの履歴トラバースコマンド。

For these commands, specifying a single revision, using the notation described in the previous section, means the set of commits reachable from the given commit.これらのコマンドでは、前のセクションで説明した表記を使用して単一のリビジョンを指定することは、特定のコミットreachableからのコミットのセットを意味します。

A commit’s reachable set is the commit itself and the commits in its ancestry chain.コミットの到達可能なセットは、コミット自体とその祖先チェーン内のコミットです。

Commit Exclusions除外をコミット

^<rev> (caret) Notation ^ <rev>(キャレット)表記

To exclude commits reachable from a commit, a prefix ^ notation is used. E.g. ^r1 r2 means commits reachable from r2 but exclude the ones reachable from r1 (i.e. r1 and its ancestors).コミットから到達可能なコミットを除外するために、接頭辞^表記が使用されます。例えば^ R1 R2の手段から到達可能なコミットR2しかしから到達可能なもの除外するR1(すなわちR1とその祖先が)。

Dotted Range Notations点線範囲表記

The .. (two-dot) Range Notation ...(2点)範囲表記

The ^r1 r2 set operation appears so often that there is a shorthand for it. When you have two commits r1 and r2 (named according to the syntax explained in SPECIFYING REVISIONS above), you can ask for commits that are reachable from r2 excluding those that are reachable from r1 by ^r1 r2 and it can be written as r1..r2.^ R1 R2の集合演算は、それほど頻繁にそれのための速記があることが表示されます。あなたは2つのコミットしていた場合、R1R2(構文に従って名前が上記のリビジョンを指定で説明)を、次の方法でR1から到達可能であるものを除くR2から到達可能なコミットを求めることができます^ R1 R2と、それは次のように書くことができR1。 .r2

The …​ (three-dot) Symmetric Difference Notation ...(3ドット)対称差表記

A similar notation r1...r2 is called symmetric difference of r1 and r2 and is defined as r1 r2 --not $(git merge-base --all r1 r2). It is the set of commits that are reachable from either one of r1 (left side) or r2 (right side) but not from both.同様の表記r1 ... r2は、r1r2の対称差と呼ばれ、r1 r2 --not $(git merge-base --all r1 r2)と定義されます。r1(左側)またはr2(右側)のどちらか一方から到達可能ですが、両方からは到達できないコミットのセットです。

In these two shorthand notations, you can omit one end and let it default to HEAD. For example, origin.. is a shorthand for origin..HEAD and asks "What did I do since I forked from the origin branch?" Similarly, ..origin is a shorthand for HEAD..origin and asks "What did the origin do since I forked from them?" Note that .. would mean HEAD..HEAD which is an empty range that is both reachable and unreachable from HEAD.これら2つの簡略表記では、片方の端を省略してデフォルトのHEADにすることができます。たとえば、origin ..origin..HEADの省略形で、「originブランチから分岐した後はどうしましたか?」と尋ねます。同様に、..originはの省略形ですHEAD..originと尋ねる「私は彼らからフォークので、起源は何をしましたの?」..はHEADから到達可能で到達不可能な空の範囲であるHEAD..HEADを意味することに注意してください。

Other <rev>^ Parent Shorthand Notationsその他の<rev> ^親の簡略表記

Three other shorthands exist, particularly useful for merge commits, for naming a set that is formed by a commit and its parent commits.コミットとその親コミットによって形成されるセットの命名に、マージコミットに特に便利な3つの他の短縮形があります。

The r1^@ notation means all parents of r1.^ @ r1の表記は、すべての親を意味R1を

The r1^! notation includes commit r1 but excludes all of its parents. By itself, this notation denotes the single commit r1.R1 ^!記法はcommit r1を含みますが、その親をすべて除外します。それ自体では、この表記は単一のコミットr1を表します。

The <rev>^-<n> notation includes <rev> but excludes the <n>th parent (i.e. a shorthand for <rev>^<n>..<rev>), with <n> = 1 if not given. This is typically useful for merge commits where you can just pass <commit>^- to get all the commits in the branch that was merged in merge commit <commit> (including <commit> itself).<REVは> ^ - <N>表記は、<REVを>が、<n>は親番目(すなわち用速記除外<REV> ^ <N> .. <REV>で)<N> = 1与えられていない場合。これは通常、merge commit <commit><commit>自体を含む)でマージされたブランチ内のすべてのコミットを取得するために<commit> ^ -を渡すことができるマージコミットに役立ちます。

While <rev>^<n> was about specifying a single commit parent, these three notations also consider its parents. For example you can say HEAD^2^@, however you cannot say HEAD^@^2.しばらく<REV> ^ <n>は、これら三つの表記は、また、その両親を考える一つのコミットの親の指定についてでした。たとえば、HEAD ^ 2 ^ @と言うことはできますが、HEAD ^ @ ^ 2と言うことはできません。

Revision Range Summary改訂範囲のまとめ


Include commits that are reachable from <rev> (i.e. <rev> and its ancestors).<rev>から到達可能なコミット(すなわち<rev>とその先祖)を含めます。

^<rev> ^ <rev>

Exclude commits that are reachable from <rev> (i.e. <rev> and its ancestors).<rev>から到達可能なコミット(すなわち<rev>とその先祖)を除外します。

<rev1>..<rev2> <rev1> .. <rev2>

Include commits that are reachable from <rev2> but exclude those that are reachable from <rev1>. When either <rev1> or <rev2> is omitted, it defaults to HEAD.<rev2>から到達可能なコミットを含めますが、<rev1>から到達可能なコミットは除外します。<rev1>または<rev2>のどちらかが省略された場合、デフォルトはになりHEADます。

<rev1>...<rev2> <rev1> ... <rev2>

Include commits that are reachable from either <rev1> or <rev2> but exclude those that are reachable from both. When either <rev1> or <rev2> is omitted, it defaults to HEAD.<rev1>または<rev2>から到達可能なコミットを含めますが、両方から到達可能なコミットは除外します。<rev1>または<rev2>のどちらかが省略された場合、デフォルトはになりHEADます。

<rev>^@, e.g. HEAD^@ <rev> ^ @、例えばHEAD ^ @

A suffix ^ followed by an at sign is the same as listing all parents of <rev> (meaning, include anything reachable from its parents, but not the commit itself).接尾辞^の後にアットマークが続くことは、<rev>のすべての親をリストするのと同じです(つまり、その親から到達可能なものはすべて含みますが、コミット自体は含みません)。

<rev>^!, e.g. HEAD^! <rev> ^!例えばHEAD ^!

A suffix ^ followed by an exclamation mark is the same as giving commit <rev> and then all its parents prefixed with ^ to exclude them (and their ancestors).感嘆符が後に続く接尾辞^は、commit <rev>を与え、それからそれらを除外するために^を前に付けてその親すべて(およびその先祖)を与えるのと同じです。

<rev>^-<n>, e.g. HEAD^-, HEAD^-2 <rev> ^ - <n>、例:HEAD ^ - 、HEAD ^ -2

Equivalent to <rev>^<n>..<rev>, with <n> = 1 if not given.相当<REV> ^ <N> .. <REV>で、<n>は = 1であれば与えられていません。

Here are a handful of examples using the Loeliger illustration above, with each step in the notation’s expansion and selection carefully spelt out:上記の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


git-rev-parse[1]git-rev-parse [1]


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