命名

git-rev-parse - Pick out and massage parameters

概要

git rev-parse [ --option ] <args>…

描述

许多Git瓷器命令会混合使用标志（即以短划线开头的参数-）以及参数，这些参数用于git rev-list它们在内部使用的基础命令，以及标志和参数用于其下游使用的其他命令git rev-list。该命令用于区分它们。

选项

操作模式

这些选项中的每一个都必须首先出现在命令行中。

--parseopt

使用git rev-parse在选项解析模式（见下文PARSEOPT部分）。

--sq-quote

使用git rev-parse的shell引用模式（见下面的SQ-报价部分）。与--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

验证只提供了一个参数，并且可以将其转换为可用于访问对象数据库的原始20字节SHA-1。如果是这样，将其发送到标准输出; 否则，出错。

如果要确保输出实际命名对象数据库中的对象并/或可以将其用作所需的特定对象类型，则可以将^{type}剥离运算符添加到参数中。例如，git rev-parse "$VAR^{commit}"将确保$VAR命名为提交ish的现有对象（即，提交或指向提交的带注释的标记）。确保可以使用$VAR任何类型的现有对象的名称git rev-parse "$VAR^{object}"。

-q   --quiet

只在--verify模式中有意义。如果第一个参数不是有效的对象名称，则不输出错误消息; 而是静静地退出非零状态。成功时，将有效对象名称的SHA-1打印到stdout。

--sq

通常每个标志和参数输出一行。此选项使输出成为单行，并且适用于shell的消耗。当你期望你的参数包含空格和换行符时（例如使用镐-S时git diff-*）很有用。与--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类似，但它省略了不是参考的输入（即分支或标签名称;或者更明确地消除“头部/主”形式的歧义，当您想命名“主”分支时，标签“master”），并将其显示为完整的refnames（例如“refs / heads / master”）。

对象的选项

--all

显示在中找到的所有参考refs/。

--branches=pattern   --tags=pattern   --remotes=pattern

显示所有分支，标签，或远程跟踪分支，分别为（即，裁判发现refs/heads，refs/tags或refs/remotes分别）。

如果pattern给出a，则只显示匹配给定shell glob的引用。如果模式不包含匹配字符（?，，*或[），则通过追加将其转换为前缀匹配/*。

--glob=pattern

显示与shell glob模式匹配的所有参考pattern。如果模式没有开始refs/，则会自动添加前缀。如果模式不包含匹配字符（?，，*或[），则通过追加将其转换为前缀匹配/*。

--exclude=<glob-pattern>

不包括裁判匹配<glob-pattern>，未来--all，--branches，--tags，--remotes，或--glob原本考虑。这个选项排除累积模式到下一个的重复--all，--branches，--tags，--remotes，或--glob选择（其他选项或参数不清除积累的模式）。

给予不应该开始的模式refs/heads，refs/tags或refs/remotes当应用到--branches，--tags或--remotes分别，他们必须开始refs/在应用于--glob或--all。如果尾随/*是有意的，则必须明确给出。

--disambiguate=<prefix>

显示名称以给定前缀开头的每个对象。<prefix>的长度必须至少为4个十六进制数字，以避免错误地列出存储库中的每个对象。

文件选项

--local-env-vars

列出存储库本地的GIT_ *环境变量（例如GIT_DIR或GIT_WORK_TREE，但不包括GIT_EDITOR）。仅列出变量的名称，而不是它们的值，即使它们已设置。

--git-dir

显示$GIT_DIR是否已定义。否则，显示.git目录的路径。显示的路径相对于当前工作目录。

如果$GIT_DIR未定义，并且未检测到当前目录位于Git存储库或工作树中，则向stderr发送消息并以非零状态退出。

--absolute-git-dir

就像--git-dir，但它的输出始终是规范化的绝对路径。

--git-common-dir

显示$GIT_COMMON_DIR是否已定义，否则$GIT_DIR。

--is-inside-git-dir

当前工作目录位于存储库目录下方时，打印“true”，否则为“false”。

--is-inside-work-tree

当前工作目录位于存储库的工作树内时，打印“true”，否则为“false”。

--is-bare-repository

当存储库是裸打印“真”，否则“假”。

--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-cdup

当从子目录调用该命令时，显示相对于当前目录的顶级目录的路径（通常是一系列“../”或空字符串）。

--show-prefix

当从子目录调用该命令时，显示当前目录相对于顶级目录的路径。

--show-toplevel

显示顶级目录的绝对路径。

--show-superproject-working-tree显示使用当前存储库作为其子模块的超级项目工作树（如果存在）的根的绝对路径。如果当前存储库未被任何项目用作子模块，则不输出。

--shared-index-path

在分割索引模式下显示共享索引文件的路径，如果不在分割索引模式下则显示空白。

其他选项

--since=datestring   --after=datestring

解析日期字符串，并输出相应的--max-age =参数git rev-list。

--until=datestring   --before=datestring

解析日期字符串，并输出相应的--min-age =参数git rev-list。

<args>…

要解析的标志和参数。

指定修订

修订参数<rev>通常（但不一定）命名提交对象。它使用所谓的extended SHA-1语法。以下是拼写对象名称的各种方法。列表附近列出的名称包含在提交中的树和blob。

<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e

完整的SHA-1对象名称（40字节的十六进制字符串）或存储库中唯一的前导子字符串。例如，dae86e1950b1277e545cee180551750029cfe735和dae86e都会命名相同的提交对象，前提是存储库中没有其他对象，其对象名称以dae86e开头。

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

输出来自git describe; 即最接近的标记，可选地后跟破折号和多个提交，后跟短划线，a g和缩写对象名称。

<refname>, e.g. master, heads/master, refs/heads/master

符号参考名称。例如master通常意味着引用的提交对象refs/heads/master。如果你碰巧有两个heads/master和tags/master，你可以明确地说heads/master要告诉Git的你的意思是哪一个。当模棱两可时，<refname>通过在以下规则中进行第一次匹配来消除a ：

1. 如果$GIT_DIR/<refname>存在，那就是你的意思（这通常是有用的，只有为HEAD，FETCH_HEAD，ORIG_HEAD，MERGE_HEAD和CHERRY_PICK_HEAD）;

1. 否则，refs/<refname>如果存在;

1. 否则，refs/tags/<refname>如果存在;

1. 否则，refs/heads/<refname>如果存在;

1. 否则，refs/remotes/<refname>如果存在;

1. 否则，refs/remotes/<refname>/HEAD如果存在。

HEAD命名您在工作树中基于更改的提交。FETCH_HEAD记录您在上次git fetch调用时从远程存储库中获取的分支。ORIG_HEAD是通过命令创建的，这些命令HEAD以激烈的方式移动您的行为，记录HEAD它们在操作之前的位置，以便您可以轻松地将分支的顶端更改回到运行之前的状态。MERGE_HEAD记录您在运行时正在合并到您的分支中的提交git merge。CHERRY_PICK_HEAD记录您在运行时正在挑选的提交git cherry-pick。

请注意，refs/*上述任何情况都可能来自$GIT_DIR/refs目录或$GIT_DIR/packed-refs文件。虽然未指定ref名称编码，但首选UTF-8，因为某些输出处理可能采用UTF-8中的ref名称。

@

@ alone is a shortcut for HEAD.

<refname>@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}

后面跟着@带括号的括号中的后缀（例如{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>）。请注意，这会在给定的时间查看当地裁判的状态; 例如master上周您当地的分支机构。如果您想查看某些时间内提交的内容，请参阅--since和--until。

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

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

@{<n>}, e.g. @{1}

您可以使用@带有空引用部分的构造来获取当前分支的reflog条目。例如，如果您在分支上，blabla则@{1}意味着与之相同blabla@{1}。

@{-<n>}, e.g. @{-1}

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

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

@{upstream}branchname（简称<branchname>@{u}）的后缀是指由branchname指定的分支设置为在（使用branch.<name>.remoteand branch.<name>.merge）配置的基础上构建的分支。缺少的branchname默认为当前的。当用大写拼写时，这些后缀也是可接受的，无论大小写是什么，它们都表示相同的事物。

<branchname>@{push}, e.g. master@{push}, @{push}

@{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

还有三个其他的shorthands，对于合并提交，对于由提交和它的父提交形成的集合进行命名特别有用。

该r1^@符号表示的所有家长r1。

该r1^!表示包括提交r1但排除其所有父母。这个符号本身表示单个提交r1。

该<rev>^-<n>符号包括<rev>但不包括<N>个亲本（即，简写<rev>^<n>..<rev>），其中<n>= 1，如果没有给出。这对合并提交通常很有用，您可以通过合并提交<commit>^-来获取合并提交中合并的分支中的所有提交<commit>（包括<commit>它自己）。

虽然<rev>^<n>是关于指定一个单一的提交父母，但这三个符号也考虑到它的父母。例如，你可以说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>^@, e.g. HEAD^@

一个后缀^后跟一个符号与列出所有父母的<rev>意思相同（意思是，包括任何可从其父母获得的东西，但不包括承诺本身）。

<rev>^!, e.g. HEAD^!

一个后缀^后跟一个感叹号的方式与提交相同<rev>，然后它的所有父母前缀^以排除它们（和它们的祖先）。

<rev>^-<n>, e.g. 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帮助按摩选项，使shell脚本拥有与C builtins相同的设施。它作为一个选项标准化器（例如拆分单个交换机聚合值），有点像getopt(1)。

它接受标准输入的解析和理解选项的规范，并在标准输出上回显一个适合于sh(1) eval用规范化参数替换参数的字符串。如果发生错误，它会在标准错误流上输出使用情况，并以代码129退出。

注意：确保在传递结果时引用结果eval。见下面的例子。

输入格式

git rev-parse --parseopt输入格式完全基于文本。它有两部分，由仅包含一行的行分隔--。分隔符之前的行（应该是一个或多个）用于使用。分隔符后面的行描述了选项。

每行选项都有以下格式：

<opt-spec><flags>*<arg-hint>? SP+ help LF

<opt-spec>

它的格式是短选项字符，然后是用逗号分隔的长选项名称。这两个部分都不是必需的，但至少需要一个。可能不包含任何<flags>字符。h,help，dry-run并且f是正确的例子<opt-spec>。

<flags>

<flags> are of *, =, ? or !.

• 如果选项带有参数，请使用=。

• 使用?意味着选项接受一个可选参数。您可能想要使用该--stuck-long模式来明确地解析可选参数。

• 使用*意味着该选项不应该在所生成的使用上市-h的说法。它显示为--help-all在gitcli [7]中记录。

• 使用!不使提供相应的否定长选项。

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

SQ-报价

在--sq-quote模式中，git rev-parse标准输出上的回声适合单线sh(1) eval。这条线是通过标准化后面的参数来完成的--sq-quote。除了引用参数外，没有其他任何事情完成了。

如果希望命令输入git rev-parse在输出被shell引用之前仍照常解释，请参阅--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 shell变量中的版本打印提交对象名称：

$ git rev-parse --verify $ REV ^ {commit}

如果$ REV为空或者不是有效的修订版，这将会出错。

• 与上面类似：

$ git rev-parse --default master --verify $REV

但如果$ REV为空，则会打印来自主服务器的提交对象名称。