git show

git-show

名称

git-show - 显示各种类型的对象

概要

git show [options] <object>…​

描述

显示一个或多个对象（二进制大型对象、树、标签和提交）。

对于提交，它显示日志消息和文本差异。它还以特殊格式显示合并提交git diff-tree --cc。

对于标签，它显示标签消息和引用的对象。

对于树，它显示名称（相当于git ls-tree仅限于 - 名称）。

对于普通的二进制大型对象，它显示简单的内容。

该命令使用适用于该git diff-tree命令的选项来控制提交引入的更改的显示方式。

本手册页仅介绍最常用的选项。

选项

<object>…​

要显示的对象的名称。有关拼写对象名称的更完整列表，请参阅 gitrevisions [7]中的“指定修订”部分。

--pretty=<format> --format=<format>

在给定的格式漂亮地打印（Pretty-print）提交日志中的内容，在这里<format>可以是一个oneline，short，medium，full，fuller，email，raw，format:<string>和tformat:<string>。当<format>没有上述情况，并且%placeholder在其中，它的行为就像--pretty=tformat:<format>是给予的一样。

有关每种格式的其他详细信息，请参阅“PRETTY FORMATS”部分。当=<format>零件被省略时，它默认为medium。

注意：您可以在存储库配置中指定默认的漂亮格式（请参阅 git-config [1]）。

--abbrev-commit

不显示完整的40字节十六进制提交对象名称，只显示部分前缀。非默认位数可以用“--abbrev = <n>”来指定（如果显示，它也会修改差异输出）。

这应该使“--pretty = oneline”对于使用80列终端的人来说更加可读。

--no-abbrev-commit

显示完整的40字节十六进制提交对象名称。这种否定--abbrev-commit和暗示它的选项如“--oneline”。它也覆盖log.abbrevCommit变量。

--oneline

这是一起使用的“--pretty = oneline --abbrev-commit”的缩写。

--encoding=<encoding>

提交对象在其编码头中记录用于日志消息的编码；这个选项可以用来告诉命令在用户首选的编码中重新编写提交日志消息。对于非管道命令，默认为 UTF-8。请注意，如果一个对象声称被编码X并且正在输出X，我们将逐字输出对象; 这意味着原始提交中的无效序列可能会被复制到输出中。

--expand-tabs=<n> --expand-tabs --no-expand-tabs

在输出中显示日志消息之前，执行一个标签扩展（将每个标签替换为足够的空格以填充下一个显示列的倍数<n>）。--expand-tabs是一种--expand-tabs=8缩写，并且--no-expand-tabs是一种--expand-tabs=0的缩写，即禁用选项卡扩展。

默认情况下，突片缩进日志消息扩展在相当格式由4个空格（即medium，这是默认值，full和fuller）。

--notes=<treeish>

在显示提交日志消息时，显示注释提交的注释（请参阅 git-notes [1]）。这是默认的git log，git show和git whatchanged命令，当没有--pretty，--format或者--oneline在命令行上给出的选项的时候。

默认情况下，显示的注释来自core.notesRef和notes.displayRef变量（或相应的环境覆盖）中列出的注释 ref 。有关更多详细信息，请参阅 git-config [1]。

使用可选<treeish>参数，使用树状图来查找要显示的注释。当它开始时，树木可以指定完整的 refname refs/notes/； 当它开始时notes/，refs/亦或是refs/notes/以前缀形成 ref 的全名。

多个 - 注释选项可以结合使用来控制显示哪些笔记。例如：“--notes = foo”将只显示“refs / notes / foo”中的注释; “--notes = foo --notes”将显示来自“refs / notes / foo”和默认注释 ref（s）的两个注释。

--no-notes

不要显示注释。这会取消上述--notes选项，方法是重置从中显示注释的注释列表。选项按照命令行给出的顺序进行解析，因此，例如“--notes --notes = foo --no-notes --notes = bar”将仅显示“refs / notes / bar”中的注释。

--show-notes=<treeish> --no-standard-notes

这些选项已被弃用。改为使用上面的 - 注释/ - 无备注选项。

--show-signature

通过签名传递gpg --verify并显示输出来检查签名提交对象的有效性。

漂亮的格式（Pretty formats）

如果提交是合并，并且不是美观格式oneline，email或者raw在该Author:行之前插入了一条附加线。该行以“Merge：”开始，并且祖先提交的sha1被打印出来，用空格分隔。请注意，如果您限制了对历史的查看，列出的提交可能不一定是直接父辈提交的列表：例如，如果您只对与某个目录或文件相关的更改感兴趣。

有几种内置格式，你可以通过设置一个漂亮的<name> config选项来定义其他格式format:，如下所述（参见 git-config [1]）。以下是内置格式的详细信息：

• oneline <sha1> <标题行>设计得尽可能紧凑。

• short

commit <sha1> Author: <author>

<title line>

• medium commit <sha1> Author: <author> Date: <author date><title line><full commit message>

• full

commit <sha1> Author: <author> Commit: <committer>

<title line>

<full commit message>

• fuller commit <sha1> Author: <author> AuthorDate: <author date> Commit: <committer> CommitDate: <committer date><title line><full commit message>

• email

From <sha1> <date> From: <author> Date: <author date> Subject: PATCH <title line>

<full commit message>

• raw raw格式示出了整个提交完全一样存储在 commit 对象。值得注意的是，无论使用--abbrev 还是--no-abbrev，SHA-1 都会全部显示，并且parents信息会显示真正的父提交，而不会考虑移植或简化历史记录。请注意，这种格式会影响提交显示的方式，但不会影响比较显示的方式git log --raw。要以原始差异格式获取完整对象名称，请使用--no-abbrev。

• format:<string>

format:<string>格式允许您指定要显示的信息。它的工作原理与 printf 格式有点相似，但有一个值得注意的例外，那就是你使用的是换行符%n而不是\n。

例如，format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"会显示这样的事情：

fe6e0ee 的作者 是Junio C Hamano，23小时前标题是>> t4119：test autocomputing -p <n>用于传统差异输入。<<

占位符是：

-  `%H`: commit hash

-  `%h`: abbreviated commit hash

-  `%T`: tree hash

-  `%t`: abbreviated tree hash

-  `%P`: parent hashes

-  `%p`: abbreviated parent hashes

-  `%an`: author name

-  `%aN`: author name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ae`: author email

-  `%aE`: author email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ad`: author date (format respects --date= option)

-  `%aD`: author date, RFC2822 style

-  `%ar`: author date, relative

-  `%at`: author date, UNIX timestamp

-  `%ai`: author date, ISO 8601-like format

-  `%aI`: author date, strict ISO 8601 format

-  `%cn`: committer name

-  `%cN`: committer name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ce`: committer email

-  `%cE`: committer email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%cd`: committer date (format respects --date= option)

-  `%cD`: committer date, RFC2822 style

-  `%cr`: committer date, relative

-  `%ct`: committer date, UNIX timestamp

-  `%ci`: committer date, ISO 8601-like format

-  `%cI`: committer date, strict ISO 8601 format

-  `%d`: ref names, like the --decorate option of [git-log[1]](git-log)

-  `%D`: ref names without the " (", ")" wrapping.

-  `%e`: encoding

-  `%s`: subject

-  `%f`: sanitized subject line, suitable for a filename

-  `%b`: body

-  `%B`: raw body (unwrapped subject and body)

-  `%N`: commit notes

-  `%GG`: raw verification message from GPG for a signed commit

-  `%G?`: show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good signature made by an expired key, "R" for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key) and "N" for no signature

-  `%GS`: show the name of the signer for a signed commit

-  `%GK`: show the key used to sign a signed commit

-  `%gD`: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2 minutes ago`}; the format follows the rules described for the `-g` option. The portion before the `@` is the refname as given on the command line (so `git log -g refs/heads/master` would yield `refs/heads/master@{0}`).

-  `%gd`: shortened reflog selector; same as `%gD`, but the refname portion is shortened for human readability (so `refs/heads/master` becomes just `master`).

-  `%gn`: reflog identity name

-  `%gN`: reflog identity name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ge`: reflog identity email

-  `%gE`: reflog identity email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%gs`: reflog subject

-  `%Cred`: switch color to red

-  `%Cgreen`: switch color to green

-  `%Cblue`: switch color to blue

-  `%Creset`: reset color

-  `%C(…​)`: color specification, as described under Values in the "CONFIGURATION FILE" section of [git-config[1]](git-config). By default, colors are shown only when enabled for log output (by `color.diff`, `color.ui`, or `--color`, and respecting the `auto` settings of the former if we are going to a terminal). `%C(auto,...)` is accepted as a historical synonym for the default (e.g., `%C(auto,red)`). Specifying `%C(always,...) will show the colors even when color is not otherwise enabled (though consider just using `--color=always` to enable color for the whole output, including this format and anything else git might color). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring on the next placeholders until the color is switched again.

-  `%m`: left (`<`), right (`>`) or boundary (`-`) mark

-  `%n`: newline

-  `%%`: a raw `%`

-  `%x00`: print a byte from a hex code

-  `%w([<w>[,<i1>[,<i2>]]])`: switch line wrapping, like the -w option of [git-shortlog[1]](git-shortlog).

-  `%<(<N>[,trunc|ltrunc|mtrunc])`: make the next placeholder take at least N columns, padding spaces on the right if necessary. Optionally truncate at the beginning (ltrunc), the middle (mtrunc) or the end (trunc) if the output is longer than N columns. Note that truncating only works correctly with N >= 2.

-  `%<|(<N>)`: make the next placeholder take at least until Nth columns, padding spaces on the right if necessary

-  `%>(<N>)`, `%>|(<N>)`: similar to `%<(<N>)`, `%<|(<N>)` respectively, but padding spaces on the left

-  `%>>(<N>)`, `%>>|(<N>)`: similar to `%>(<N>)`, `%>|(<N>)` respectively, except that if the next placeholder takes more spaces than given and there are spaces on its left, use those spaces

-  `%><(<N>)`, `%><|(<N>)`: similar to `% <(<N>)`, `%<|(<N>)` respectively, but padding both sides (i.e. the text is centered)

-  %(trailers): display the trailers of the body as interpreted by [git-interpret-trailers[1]](git-interpret-trailers)NoteSome placeholders may depend on other options given to the revision traversal engine. For example, the %g* reflog options will insert an empty string unless we are traversing reflog entries (e.g., by git log -g). The %d and %D placeholders will use the "short" decoration format if --decorate was not already provided on the command line.If you add a + (plus sign) after % of a placeholder, a line-feed is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.If you add a - (minus sign) after % of a placeholder, all consecutive line-feeds immediately preceding the expansion are deleted if and only if the placeholder expands to an empty string.If you add a  (space) after % of a placeholder, a space is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.tformat:

tformat:格式的操作完全相同format:，不同之处在于它提供了“终结者”的语义，而不是“分隔符”的语义。换句话说，每个提交都附加了消息结束符（通常是一个换行符），而不是放置在条目之间的分隔符。这意味着单行格式的最终​​条目将以新的行正确终止，就像“oneline”格式一样。例如：

$ git log -2 --pretty=format:%h 4da45bef \ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973 -- NO NEWLINE $ git log -2 --pretty=tformat:%h 4da45bef \ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973

另外，任何无法识别的字符串%都会被解释为在tformat:前面。例如，这两个是等价的：

$ git log -2 --pretty=tformat:%h 4da45bef $ git log -2 --pretty=%h 4da45bef

常见的差异选项

-p -u --patch

生成补丁（请参阅生成补丁一节）。

-s --no-patch

抑制差异输出。对于像git show这样的命令很有用，默认显示补丁，或者取消效果--patch。

-U<n> --unified=<n>

使用<n>行上下文生成差异，而不是通常的三行。意味着-p。

--raw

对于每个提交，使用原始 diff格 式显示更改的摘要。请参阅 git-diff [1]的“RAW OUTPUT FORMAT”部分。这与以原始格式显示日志本身不同，您可以使用它--format=raw。

--patch-with-raw

-p --raw的同义词。

--indent-heuristic --no-indent-heuristic

这些是为了帮助调试和调整实验启发式（默认情况下是关闭的），这些启发式技术改变了差异边界以使修补程序更易于阅读。

--minimal

花费额外的时间来确保生成最小可能的差异。

--patience

使用“耐心差异”算法生成差异。

--histogram

使用“直方图差异”算法生成差异。

--diff-algorithm={patience|minimal|histogram|myers}

选择一种差异算法。变体如下：

default, myers

基本的贪婪的 diff 算法。目前，这是默认设置。

minimal

花费额外的时间来确保生成最小可能的差异。

patience

生成补丁时使用“耐心差异”算法。

histogram

该算法将耐心算法扩展为“支持低出现率的通用元素”。

例如，如果将 diff.algorithm 变量配置为非默认值并希望使用默认值，则必须使用--diff-algorithm=default选项。

--stat[=<width>[,<name-width>,<count>]]

生成一个 diffstat。默认情况下，文件名部分使用尽可能多的空间，其余部分使用图形部分。最大宽度默认为终端宽度，如果未连接到终端，则最大宽度为80列，并且可以被覆盖<width>。文件名部分的宽度可以通过<name-width>逗号后面的另一个宽度来限制。图形部分的宽度可以通过使用--stat-graph-width=<width>（影响所有生成统计图的命令）或通过设置diff.statGraphWidth=<width>（不影响git format-patch）来限制。通过给出第三个参数<count>，可以将输出限制在第一<count>行，紧接着...（如果还有更多的话）。

这些参数也可以单独设置--stat-width=<width>，--stat-name-width=<name-width>和--stat-count=<count>。

--numstat

类似于--stat，但显示十进制表示法中添加和删除的行数以及不带缩写的路径名，以使其更加机器友好。对于二进制文件，输出两个-而不是说0 0。

--shortstat

只输出包含修改文件总数的格式--stat的最后一行，以及添加和删除行的数量。

--dirstat=<param1,param2,…​>

输出每个子目录的相对变化量分布。可以通过传递一个用逗号分隔的参数列表来定制--dirstat行为。默认值由diff.dirstat配置变量控制（请参 阅git-config [1]）。以下参数可用：

changes

通过计算已从源中删除或添加到目标的行来计算 dirstat 数字。这会忽略文件中纯代码移动的数量。换句话说，重新排列文件中的行数不会与其他更改一样多。这是没有给出参数时的默认行为。

lines

通过执行常规基于行的差异分析来计算 dirstat 数字，并且将移除/添加的行数相加。（对于二进制文件，取而代之的是计算64字节的块，因为二进制文件没有自然的行概念）。这是一种--dirstat比changes行为更为昂贵的行为，但它可以像其他更改一样对文件中的重新排列的行进行计数。结果输出与您从其他--*stat选项中获得的结果一致。

files

通过计算更改的文件数量来计算 dirstat 数字。在dirstat 分析中每个更改的文件都相同。这是计算上最便宜的--dirstat行为，因为它根本不需要查看文件内容。

cumulative

计数父目录的子目录中的更改。请注意，使用时cumulative，报告的百分比总和可能超过100％。默认（非累积）行为可以用noncumulative参数指定。

<limit>

整数参数指定截断百分比（默认为3％）。输出中不显示贡献小于此百分比的目录。

示例：以下内容将计数已更改的文件，同时忽略占已更改文件总数少于10％的目录，并累积父目录中的子目录计数：--dirstat=files,10,cumulative。

--summary

输出扩展头信息的精简摘要，如创建、重命名和模式更改。

--patch-with-stat

-p --stat=的同义词。

-z

用 NUL 分开提交，而不用新的换行符。

此外，当--raw或--numstat已经被给出的时候，请勿使用路径名并将 NUL 用作输出字段终止符。

如果没有这个选项，带有“不寻常”字符的路径名将按照配置变量core.quotePath的说明引用（请参阅 git-config [1]）。

--name-only

仅显示已更改文件的名称。

--name-status

仅显示已更改文件的名称和状态。有关--diff-filter状态字母的含义，请参阅选项说明。

--submodule=<format>

指定如何显示子模块中的差异。指定使用--submodule=short的short格式时。这种格式只显示范围开始和结束处的提交名称。当--submodule或者--submodule=log被指定时，使用log格式。这种格式列出了像 git-submodule [1] summary那样的提交。当--submodule=diff指定时，使用diff格式。这种格式显示了提交范围内子模块内容变化的内联比较。如果配置选项未设置，则默认为diff.submodule或short格式。

--color=<when>

显示有色差异。--color（即没有=<when>）是一样的--color=always。<when>可以是一个always，never或auto。

--no-color

关闭有色差异。它和--color=never。一样。

--word-diff=<mode>

显示一个单词diff，使用<mode>分隔已更改的单词。默认情况下，单词由空格分隔; 见--word-diff-regex下文。<mode>默认为plain，并且必须是以下之一：

color

仅使用颜色突出显示更改的词。意味着--color。

plain

将单词显示为[-removed-]和{+added+}。如果输入中出现分隔符，则不会尝试跳过分隔符，因此输出可能不明确。

porcelain

使用专门用于脚本消费量的基于行的格式。以通常的统一差异格式打印已添加/已删除/未更改的运行，以行开始处的+/ -/字符开始并延伸至行尾。输入中~的换行符通过它自己的一行代字符表示。

none

再次禁用字差异。

请注意，尽管第一个模式的名称，如果启用，颜色将用于突出显示所有模式中更改的部分。

--word-diff-regex=<regex>

使用<regex>来决定一个单词是什么，而不是将非空白的运行视为一个单词。也意味着--word-diff除非已经启用。

每个<regex>的非重叠匹配都被视为一个单词。为了找到差异，这些匹配之间的任何内容都被认为是空白并被忽略(!) 。你可能想追加|[^[:space:]]到你的正则表达式，以确保它匹配所有非空白字符。包含换行符的匹配在换行符处被无提地截断(!)。

例如，--word-diff-regex=.将每个字符看作单词，并相应地逐个字符地显示差异。

正则表达式也可以通过 diff 驱动程序或配置选项来设置，请参阅 gitattributes [5]或git-config [1]。显式给予它将覆盖任何 diff 驱动程序或配置设置。差异驱动程序覆盖配置设置

--color-words=<regex>

相当于--word-diff=color加（如果指定了正则表达式）--word-diff-regex=<regex>。

--no-renames

关闭重命名检测，即使配置文件提供了默认设置。

--check

警告如果更改引入冲突标记或空白错误。认为空白错误是由core.whitespace配置控制的。默认情况下，尾随空格（包括单独由空格组成的行）和空格字符（紧跟该行的初始缩进内的制表符后面的空格字符）将被视为空白错误。如果发现问题，则退出非零状态。与--exit-code 不兼容。

--ws-error-highlight=<kind>

在context、old或new差异线中突出显示空白的错误。多个值以逗号分隔，none重置以前的值，default将列表重置为new和all简写为old,new,context。如果未给出此选项，并且diff.wsErrorHighlight未设置配置变量，则只会突出显示new行中的空白错误。空白错误是彩色的color.diff.whitespace。

--full-index

在生成补丁格式输出时，在“索引”行上显示完整的映像前和映像后blob对象名称，而不是第一批字符。

--binary

除了--full-index，输出一个可以应用git-apply的二进制差异。

--abbrev=<n>

代替在 diff-raw 格式输出和 diff-tree 标题行中显示完整的40字节十六进制对象名称，只显示部分前缀。这与--full-index上面的选项无关，后者控制 diff-patch输出格式。非默认的位数可以用指定--abbrev=<n>。

-B<n> --break-rewrites[=<n>]

将完全重写更改分解为删除和创建对。这有两个目的：

它影响到一种改变的方式，这种改变相当于整个文件的重写，而不是像一系列删除和插入混合在一起，只有几行文字与上下文相匹配，而是作为旧的一切的一次删除，单次插入所有新事物，并且数字m控制-B 选项的这个方面（默认为60％）。-B/70%指定只有少于30％的原始数据应保留在 Git 的结果中，以便将其视为全部重写（否则结果补丁将是一系列与上下文行混合的删除和插入）。

与-M 一起使用时，完全重写的文件也被认为是重命名的来源（通常-M仅考虑作为重命名源消失的文件），并且该数字n控制着-B 选项的这个方面（默认为50％）。-B20%指定添加和删除相对于文件大小的20％或更多的更改有资格作为可能的重命名源到另一个文件。

-M<n> --find-renames=<n>

如果生成差异，则检测并报告每次提交的重命名。在遍历历史记录时跨越重命名后续文件，请参阅--follow。如果n被指定，则它是相似度指数的阈值（即与文件大小相比的添加/删除量）。例如，-M90%如果超过90％的文件没有改变，Git应该考虑删除/添加对是一个重命名。如果没有%符号，该数字应作为分数读取，并在其前面加小数点。即，-M5变成0.5，并且因此是相同的-M50%。同样的，-M05也是一样的-M5%。要将检测限制为精确重命名，请使用-M100%。默认相似度指数为50％。

-C<n> --find-copies=<n>

检测副本以及重命名。另见--find-copies-harder。如果n被指定，它的含义与-M<n>一致。

--find-copies-harder

出于性能原因，默认情况下，-C只有当副本的原始文件在相同的变更集中被修改时，选项才会查找副本。该标志使命令检查未修改的文件作为复制源的候选项。对于大型项目来说，这是一项非常昂贵的操作，因此请谨慎使用。给予多个-C选项具有相同的效果。

-D --irreversible-delete

省略原图像进行删除，即仅打印标题，但不打印原像和之间的差异/dev/null。由此产生的补丁不适用于patch或git apply; 这仅适用于那些想专注于更改后查看文本的人。另外，输出显然缺乏足够的信息来反向应用这样的补丁，甚至是手动的，因此也就是选项的名称。

在与-B删除/创建对的删除部分一起使用时，还要省略原图。

-l<num>

在-M和-C选项需要为 O（n ^ 2）的处理时间，其中 n 是/复制目标潜在的重命名的数目。如果重命名/复制目标的数量超过指定的数量，则此选项可防止重命名/复制检测运行。

--diff-filter=[(A|C|D|M|R|T|U|X|B)…​*]

只选择已添加（A），已复制（C），已删除（），已D修改（M），已重命名（R），其类型（即常规文件，符号链接，子模块，...）已更改（T），已取消合并（U）未知（X）或已配对的被破坏的（B）。可以使用任何过滤字符的组合（包括无）。当*（全部或无）添加到组合中时，如果有任何文件与比较中的其他条件匹配，则选择所有路径; 如果没有与其他标准匹配的文件，则不会选择任何内容。

此外，这些大写字母可以降低排除。例如--diff-filter=ad排除添加和删除的路径。

-S<string>

查找改变文件中指定字符串出现次数（即添加/删除）的差异。旨在供脚本编写者的使用。

当你寻找一个精确的代码块（比如一个结构体）并且想要知道该块自第一次出现以来的历史记录时，它非常有用：迭代地使用该特征将原始图像中的有趣块返回到-S，并继续前进，直到获得该块的第一个版本。

-G<regex>

寻找补丁文本包含与<regex>匹配的添加/删除行的差异。

为了说明之间-S<regex> --pickaxe-regex和-G<regex>的区别，考虑在同一个文件中的以下 DIFF 提交：

+    return !regexec(regexp, two->ptr, 1, &regmatch, 0
...
-    hit = !regexec(regexp, mf2.ptr, 1, &regmatch, 0

虽然git log -G"regexec\(regexp"会显示此提交，但git log -S"regexec\(regexp" --pickaxe-regex不会（因为该字符串的出现次数没有改变）。

有关pickaxe更多信息，请参阅 gitdiffcore [7]中的条目。

--pickaxe-all

当-S或-G发现更改时，显示该更改集中的所有更改，而不仅仅是包含<string>中的更改的文件。

--pickaxe-regex

将给定-S的<string> 视为扩展的 POSIX 正则表达式进行匹配。

-O<orderfile>

控制文件在输出中出现的顺序。这覆盖了diff.orderFile配置变量（请参阅 git-config [1]）。取消diff.orderFile，使用-O/dev/null。

输出顺序由<orderfile>中的全局模式顺序决定。所有具有与第一个模式相匹配的路径名的文件将首先输出，接下来将输出所有具有匹配第二个模式（但不是第一个）的路径名的文件，依此类推。最后输出所有不匹配任何模式的路径名的文件，就好像文件末尾有一个隐含的匹配模式一样。如果多个路径名具有相同的排名（它们匹配相同的模式但没有更早的模式），则它们的输出顺序相对于彼此是正常顺序。

按以下方式解析<orderfile>：

• 空白行被忽略，所以它们可以用作分隔符以提高可读性。

• 以散列（“ #”）开头的行会被忽略，因此它们可以用于注释。如果以散列开头，则在模式的开头添加反斜杠（“ \”）。

• 每个其他行都包含一个 pattern.atterns 与没有 FNM_PATHNAME 标志的 fnmantch（3）使用的模式具有相同的语法和语义，除非路径名也匹配模式，如果删除任何数量的最终路径名组件都与该模式匹配。例如，模式“ foo*bar”匹配“ fooasdfbar”和“ foo/bar/baz/asdf”但不是“foobarx即使一行有空白，而另一行没有空白，这也会忽略差异。--ignore-blank-lines忽略其行全部空白的更改。--inter-hunk-context = <lines>在 diff hunk 之间显示上下文，直到指定的行数，从而融合彼此接近的hunk。默认为diff.interHunkContext如果配置选项未设置，则为0。-W --function-context 显示更改的整个周围功能。--ext-diff 允许执行一个外部diff助手。如果你用 gitattributes [5]设置外部差异驱动程序，你需要在 git-log [1]和朋友中使用这个选项。--no-ext-diff 禁止外部 diff 驱动程序。--textconv --no-textconv 允许（或不允许）在比较二进制文件时运行外部文本转换过滤器。有关详细信息，请参阅gitattributes [5]。由于 textconv过滤器通常是单向转换，因此生成的差异适合人类消费，但无法应用。出于这个原因，默认情况下，textconv 过滤器仅针对 git-diff [1]和 git-log [1]启用，但不适用于 git-format-patch [1]或 diff plumbing命令。 - 忽略子模块= <时> 忽略差异代中子模块的更改。<when>可以是“none”，“untracked”，“dirty”或“all”，这是默认设置。如果子模块包含未跟踪或已修改的文件，或者HEAD与超级项目中记录的提交不同，并且可用于覆盖ignore选项在 git-config [1]或 gitmodules [5]中。当使用“未跟踪”时，如果子模块仅包含未跟踪内容（但仍然针对修改内容进行扫描），则子模块不会被视为脏。使用“dirty”会忽略对子模块工作树的所有更改，只会显示超级项目中存储的提交更改（这是1.7.0之前的行为）。使用“all”隐藏对子模块的所有更改。--src-prefix = <prefix>显示给定的源前缀而不是“a /”。--dst-prefix = <prefix>显示给定的目标前缀而不是“b /”。--no-prefix不显示任何源或目标前缀。--line-prefix = <prefix>为每行输出添加一个附加前缀。--ita -in-in-index默认条目由“git add -N”添加 在“git diff”中显示为现有的空文件，在“git diff --cached”中显示为新文件。这个选项使条目在“git diff”中显示为新文件，在“git diff --cached”中不存在。这个选项可以恢复--ita-visible-in-index。这两个选项都是实验性的，可以在将来删除。有关这些常用选项的更多详细说明，另请参阅gitdiffcore [7]。使用-p生成补丁当“git-diff-index”，“git-diff-tree”或“ git-diff-files“是用一个-p选项运行的，”git diff“没有--raw选项，或者”git log“用”-p“选项运行，它们不会产生上面描述的输出; 相反，他们生成一个补丁文件。您可以通过GIT_EXTERNAL_DIFF和GIT_DIFF_OPTS环境变量自定义这些修补程序的创建。-p选项生成的内容与传统的 diff 格式略有不同：

• 它前面有一个“git diff”header，看起来像这样：

diff --git a/file1 b/file2

在a/和b/文件名是，除非重命名/副本所涉及的相同。尤其是，即使是创建或删除，/dev/null也可not用于替换文件名a/或b/文件名。

当重命名/复制参与，file1并file2示出了重命名/复制的源文件的名称和重命名/复制分别产生，该文件的名称。

• 它后跟一个或多个扩展标题行：旧模式<mode>新模式<mode>已删除文件模式<mode>新文件模式<mode>从<path>复制到<path>从<path>重命名重命名为<path>相似索引<number>不相似索引<number>索引<hash> .. <hash> <mode>文件模式打印为6位八进制数字，包括文件类型和文件权限位。扩展头中的路径名不包含a/和b/前缀。相似性指数是未改变的行的百分比，不相似性指数是改变的行的百分比。它是一个向下舍入的整数，后面跟着一个百分号。100％的相似性指数值因此保留给两个相同的文件，而100％相异性意味着来自旧文件的任何行都不会将其转换为新的文件。索引行包含更改前后的 SHA-1校验和。如果文件模式没有改变，则包含<mode>; 否则，单独的行表示旧模式和新模式。

带有“不常用”字符的路径名将按照配置变量的说明引用core.quotePath（请参阅 git-config [1]）。

file1输出中的所有文件在提交之前引用文件，所有file2文件在提交之后引用文件。将每个更改顺序应用于每个文件是不正确的。例如，这个补丁会将 a 和 b ：diff --git a / ab / b 重命名为 a 重命名为 b diff --git a / bb / a 重命名为 b 重命名为 aCombined diff formatAny diff-generating 命令可以将-c或者显示合并时--cc产生一个选项combined diff。这是显示与 git-diff [1]或 git-show [1]合并时的默认格式。另请注意，您可以-m选择这些命令中的任何一个来强制生成合并的单个父代的差异combined diff格式如下所示

它前面有一个“git diff”头，看起来像这样（当使用-c选项时）：

差异组合文件

或者像这样（当使用--cc选项时）：

diff --cc file

它后面跟着一个或多个扩展标题行（此示例显示与两个父级合并）：

紧接着是两行文件/文件头

--- a/file +++ b/file

类似于传统unified差异格式的双行标题，/dev/null用于表示创建或删除的文件。

块头格式被修改以防止人们意外地将其提供给patch -p1。组合的差异格式是为了审查合并提交更改而创建的，并不适用于应用。这个改变类似于扩展index头中的改变：@@@ <从文件范围到<从文件范围到<到文件范围> @@@有（父数+ 1）个@字符不同于传统的unifieddiff格式，它显示两个文件A和B，其中有一列-（减号 - 出现在A中，但在B中删除），+（加 - 在A中丢失，但添加到B中） ， 要么" "（空格不变）前缀，此格式将两个或多个文件file1，file2，...与一个文件X进行比较，并显示X与每个fileN的区别。每个fileN的一列都被预置在输出行中，以指出X的行与其不同。-列N中的一个字符表示该行出现在fileN 中，但它不出现在结果中。+N列中的一个字符表示该行出现在结果中，并且fileN没有该行（换句话说，从该父母的视角添加该行）。在上面的示例输出中，函数签名从两个文件中更改（因此-从file1和file2中删除了两个删除，另外还有两个删除++意味着添加的一行不会出现在file1或file2中）。另外还有八行与file1相同，但不会出现在file2中（因此前缀为+）。当显示时git diff-tree -c，它将合并提交的父项与合并结果（即file1..fileN是父项）进行比较。如图所示git diff-files -c，它将两个未解决的合并父代与正在工作的树文件进行比较（即file1是第二阶段aka“我们的版本”，file2是第三阶段aka“他们的版本”）。示例 git show v1.0.0 显示标记v1.0.0以及标记指向。 git show v1.0.0^{tree} 显示标签指向的树v1.0.0。 git show -s --format=%s v1.0.0^{commit} 显示标签指向的提交主题v1.0.0。 git show next~10:Documentation/README 显示文件的内容Documentation/README因为他们是该分支最后一次承诺的第10次next。 git show master:Makefile master:t/Makefile 将分支头部中的所述Makefiles的内容连接master在一起.DiscussionGit在某种程度上是字符编码不可知的。

blob对象的内容是未解释的字节序列。在核心层面没有编码翻译。

• 路径名以 UTF-8标准化形式C编码。这适用于树对象，索引文件，ref 名称，以及命令行参数，环境变量和配置文件中的路径名.git/config（请参阅 git-config [1]） ，gitignore [5]，gitattributes [5]和gitmodules [5]）。请注意，核心级Git将路径名视为非NUL字节序列，不存在路径名编码转换（Mac和Windows除外）。因此，即使在使用传统扩展 ASCII 编码的平台和文件系统上，使用非 ASCII 路径名也可以工作。但是，在这些系统上创建的存储库在基于 UTF-8的系统（例如 Linux，Mac，Windows）上无法正常工作，反之亦然。此外，许多基 于Git 的工具只是假设路径名称为 UTF-8，并且无法正确显示其他编码。

• 提交日志消息通常以 UTF-8编码，但也支持其他扩展 ASCII 编码。这包括 ISO-8859-x，CP125x 和许多其他版本，但notUTF-16/32，EBCDIC和CJK 多字节编码（GBK，Shift-JIS，Big5，EUC-x，CP9xx 等）。

虽然我们鼓励提交日志消息使用UTF-8编码，但核心和Git瓷器都设计为不强制项目使用UTF-8。如果特定项目的所有参与者发现使用遗留编码更方便，Git不会禁止它。但是，有几件事要牢记。

git commit和git commit-tree如果提交给它的提交日志消息看起来不像一个有效的 UTF-8 字符串，则会发出警告，除非您明确声明您的项目使用了旧版编码。这样说的方式是在.git/config文件中使用 i18n.commitencoding ，如下所示： i18n commitEncoding = ISO-8859-1Commit 用上述设置创建的对象记录i18n.commitEncoding其encoding标头中的值。这是为了帮助稍后看到他们的其他人。缺少这个头部意味着提交日志消息以UTF-8编码。

git log，git show，git blame和朋友看encoding一个提交对象的报头，并且尝试除非另有规定重新代码日志消息转换成 UTF-8。您可以i18n.logOutputEncoding在.git/config文件中指定所需的输出编码，如下所示：

i18n logOutputEncoding = ISO-8859-1

如果您没有此配置变量，i18n.commitEncoding则会使用该值。

请注意，在提交对象级别强制使用 UTF-8时，我们故意选择不重新编写提交日志消息，因为重新编码为 UTF-8不一定是可逆操作。