## 命名

git-show-ref - 在本地存储库中列出引用

后缀为`@`带括号的后缀（例如`{1}`，`{15}`）指定了该ref的第n个前置值。例如`master@{1}`，`master`while `master@{5}`是第5个先前值的即时先验值`master`。该后缀只能在ref名称后面使用，并且ref必须具有现有的日志（`$GIT_DIR/logs/<refname>`）。

    git show-ref [-q|--quiet] [--verify] [--head] [-d|--dereference]             [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags]             [--heads] [--] [<pattern>…]git show-ref --exclude-existing[=<pattern>]

## 描述

显示本地存储库中可用的引用以及关联的提交ID。可以使用模式过滤结果，并可以将标记解引用到对象ID中。此外，它可以用来测试一个特定的ref是否存在。

该构造`@{-<n>}`意味着在当前之前检出的第n个分支/提交。

--exclude-existing表单是一个反过来的过滤器。它从stdin中读取ref，每行一个ref，并显示那些不存在于本地存储库中的文件。

鼓励使用此实用程序，以便直接访问目录下的`.git`文件。

## 选项

`@{push}`如果在检出时`git push`运行`branchname`（或当前`HEAD`没有指定branchname），后缀将报告分支“我们将推送到哪里” 。由于我们的推送目标位于远程存储库中，当然，我们会报告与该分支对应的本地跟踪分支（即，某处`refs/remotes/`）。

这里有一个例子可以使它更加清晰：

    $ git config push.default current

    $ git config remote.pushdefault myfork

    $ git checkout -b 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>^, e.g. HEAD^, v1.5.1^0

`^`修订参数的后缀表示该提交对象的第一个父代。`^<n>`意味着第n个父母（即`<rev>^`相当于`<rev>^1`）。作为一个特殊规则，`<rev>^0`意味着提交本身，并在`<rev>`引用提交对象的标记对象的对象名称时使用。

<rev>~<n>, e.g. master~3

`~<n>`修订参数的后缀表示作为指定提交对象的第n代祖先的提交对象，仅在第一个父代之后。即`<rev>~3`相当于`<rev>^^^`哪个相当于`<rev>^1^1^1`。请参阅下面的表格来说明此表格的用法。

<rev>^{<type>}, e.g. v0.99.8^{commit}

一个后缀`^`跟在括号内的对象类型名称意味着以`<rev>`递归方式解引用对象，直到`<type>`找到类型的对象或者对象不能被解除引用（在这种情况下，barf）。例如，如果`<rev>`是commit-ish，则`<rev>^{commit}`描述相应的提交对象。同样，如果`<rev>`是树型，则`<rev>^{tree}`描述相应的树型对象。`<rev>^0`是短暂的`<rev>^{commit}`。

`rev^{object}`可以用来确定`rev`存在的对象的名称，而不需要`rev`作为标签，也不需要解引用`rev`; 因为一个标签已经是一个对象，所以即使一次到达一个对象也不需要解除引用。

`rev^{tag}`可以用来确保`rev`识别现有的标签对象。

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

一个后缀`^`跟一个空括号对意味着对象可以是一个标签，并递归地引用标签，直到找到一个非标签对象。

<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}

后缀`^`的修正参数，其次，它包含用斜线为首的文本的一对括号，是一样的`:/fix nasty bug`下面的语法不同之处在于它返回最年轻的匹配提交其是从可到达`<rev>`之前`^`。

:/<text>, e.g. :/fix nasty bug

一个冒号，后跟一个斜线，后跟一个文本，命名提交消息与指定正则表达式匹配的提交。该名称返回可从任何ref访问的最年轻匹配提交。正则表达式可以匹配提交消息的任何部分。要匹配以字符串开头的消息，可以使用例如`:/^foo`。特殊序列`:/!`保留给修饰符以匹配内容。`:/!-foo`执行否定匹配，同时`:/!!foo`匹配文字`!`字符，然后匹配`foo`。任何以其他序列开始的序列`:/!`现在都被保留。

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

一个后缀`:`后面跟着一个路径的名称是由冒号前部分命名的tree-ish对象中给定路径上的blob或树。`:path`（在冒号前有一个空白部分）是下面描述的语法的特例：记录在给定路径索引处的内容。以当前工作目录开始`./`或`../`相对于当前工作目录的路径。给定的路径将被转换为相对于工作树的根目录。这对于从具有与工作树相同树结构的提交或树来处理blob或树是非常有用的。

:<n>:<path>, e.g. :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^0B = A^   = A^1     = A~1C = A^2  = A^2D = A^^  = A^1^1   = A~2E = B^2  = A^^2F = B^3  = A^^3G = A^^^ = A^1^1^1 = A~3H = D^2  = B^^2    = A^^^2  = A~2^2I = F^   = B^3^    = A^^3^J = F^2  = B^3^2   = A^^3^2

## 指定范围

历史遍历命令，例如`git log`对一组提交进行操作，而不仅仅是一次提交。

对于这些命令，使用上一节中描述的符号来指定单个修订，意味着`reachable`来自给定提交的一组提交。

提交的可达集是提交本身和祖先链中的提交。

### 提交排除

^<rev> (caret) Notation

要排除提交可达的提交，使用前缀`^`符号。例如，`^r1 r2`意味着提交可达，`r2`但不包括从`r1`（即`r1`其祖先）可达的。

### 虚线表示法

The .. (two-dot) Range Notation

该`^r1 r2`组操作似乎经常有它的简写。当你有两个提交`r1`并且`r2`（根据上面指定版本中所述的语法命名）时，你可以要求提交从r2到达的提交，但不包括从r1到达的那些提交，`^r1 r2`它可以写为`r1..r2`。

The … (three dot) Symmetric Difference Notation

类似的符号`r1...r2`被称为和的对称差，`r1`并被`r2`定义为`r1 r2 --not $(git merge-base --all r1 r2)`。它是从`r1`（左侧）或`r2`（右侧）中的任一个可达的提交集合，但不是来自两者。

在这两个简写符号中，可以省略一端，并将其默认为HEAD。例如，`origin..`是一个简写，`origin..HEAD`并问“自从我从原始分支分出后，我做了什么？” 同样，它`..origin`也是一种速记，`HEAD..origin`并问道：“我从他们身上分离出来后，起源究竟发生了什么？” 请注意，`..`这意味着`HEAD..HEAD`哪个空白区域可以从HEAD到达和无法到达。

### Other <rev>^ Parent Shorthand Notations