Git
英语 ▾ 主题 ▾ 最新版本 ▾ git-show 最后更新于 2.46.0

名称

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

概要

git show [<options>] [<object>…​]

描述

显示一个或多个对象(blob、树、标签和提交)。

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

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

对于树,它显示名称(等效于带有 --name-only 的 git ls-tree)。

对于普通 blob,它显示普通内容。

git log 命令理解的某些选项可用于控制提交引入的更改的显示方式。

此手册页仅描述最常用的选项。

选项

<object>…​

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

--pretty[=<format>]
--format=<format>

以给定格式漂亮地打印提交日志的内容,其中 <format> 可以是 onelineshortmediumfullfullerreferenceemailrawformat:<string>tformat:<string> 之一。当 <format> 不是上述任何一个,并且包含 %placeholder 时,它会像给出 --pretty=tformat:<format> 一样起作用。

请参阅“漂亮格式”部分,了解每种格式的更多详细信息。当省略 =<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 编码输出,则我们将原样输出该对象;这意味着原始提交中的无效序列可能会复制到输出中。同样,如果 iconv(3) 无法转换提交,我们将静默地原样输出原始对象。

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

在日志消息中执行制表符扩展(用足够多的空格替换每个制表符以填充到下一个显示列,该列是 <n> 的倍数),然后在输出中显示它。--expand-tabs--expand-tabs=8 的简写,--no-expand-tabs--expand-tabs=0 的简写,它会禁用制表符扩展。

默认情况下,制表符会在以 4 个空格缩进日志消息的漂亮格式中扩展(即 medium,它是默认值,fullfuller)。

--notes[=<ref>]

显示注释(请参阅 git-notes[1])该注释注解提交,当显示提交日志消息时。这是 git loggit showgit whatchanged 命令在命令行中未给出 --pretty--format--oneline 选项时的默认行为。

默认情况下,显示的注释来自 core.notesRefnotes.displayRef 变量中列出的注释引用(或相应的环境覆盖)。有关更多详细信息,请参阅 git-config[1]

使用可选的 <ref> 参数,使用该引用查找要显示的注释。当该引用以 refs/notes/ 开头时,它可以指定完整的引用名称;当它以 notes/ 开头时,refs/ 以及其他情况下 refs/notes/ 将被添加为前缀以形成引用的完整名称。

可以组合多个 --notes 选项来控制要显示的注释。例如:"--notes=foo" 将仅显示来自 "refs/notes/foo" 的注释;"--notes=foo --notes" 将显示来自 "refs/notes/foo" 和默认注释引用的注释。

--no-notes

不要显示注释。这会否定上面的 --notes 选项,方法是重置要从中显示注释的注释引用的列表。选项按在命令行中给出的顺序解析,因此例如 "--notes --notes=foo --no-notes --notes=bar" 将只显示来自 "refs/notes/bar" 的注释。

--show-notes-by-default

显示默认注释,除非给出显示特定注释的选项。

--show-notes[=<ref>]
--[no-]standard-notes

这些选项已弃用。请改用上面的 --notes/--no-notes 选项。

--show-signature

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

漂亮格式

如果提交是合并提交,并且漂亮格式不是 onelineemailraw,则会在 Author: 行之前插入一行。此行以 "Merge: " 开头,并打印祖先提交的哈希值,空格分隔。请注意,如果您限制了历史记录的视图,列出的提交可能不一定是直接父提交的列表:例如,如果您只对与特定目录或文件相关的更改感兴趣。

有几种内置格式,您可以通过将 pretty.<name> 配置选项设置为另一个格式名称或 format: 字符串来定义其他格式,如下所述(请参阅 git-config[1])。以下是对内置格式的详细信息

  • oneline

    <hash> <title-line>

    这旨在尽可能紧凑。

  • short

    commit <hash>
    Author: <author>
    <title-line>
  • medium

    commit <hash>
    Author: <author>
    Date:   <author-date>
    <title-line>
    <full-commit-message>
  • full

    commit <hash>
    Author: <author>
    Commit: <committer>
    <title-line>
    <full-commit-message>
  • fuller

    commit <hash>
    Author:     <author>
    AuthorDate: <author-date>
    Commit:     <committer>
    CommitDate: <committer-date>
    <title-line>
    <full-commit-message>
  • reference

    <abbrev-hash> (<title-line>, <short-author-date>)

    此格式用于在提交信息中引用另一个提交,与 --pretty='format:%C(auto)%h (%s, %ad)' 相同。默认情况下,日期格式为 --date=short,除非显式指定其他 --date 选项。与任何带有格式占位符的 format: 一样,其输出不受其他选项(如 --decorate--walk-reflogs)的影响。

  • email

    From <hash> <date>
    From: <author>
    Date: <author-date>
    Subject: [PATCH] <title-line>
    <full-commit-message>
  • mboxrd

    email 类似,但提交信息中以“From ”(前面有零个或多个“>”)开头的行将用“>” 引用,这样就不会将其与新提交的开始混淆。

  • raw

    raw 格式显示了与存储在提交对象中完全相同的整个提交。值得注意的是,无论使用 --abbrev 还是 --no-abbrev,哈希值都将以完整形式显示,并且 parents 信息将显示真实的父提交,而不会考虑嫁接或历史简化。请注意,此格式会影响提交的显示方式,但不会影响 diff 的显示方式,例如使用 git log --raw。要在原始 diff 格式中获取完整的对象名称,请使用 --no-abbrev

  • format:<format-string>

    format:<format-string> 格式允许您指定要显示的信息。它有点像 printf 格式,但有一个显著的例外,即使用 %n 而不是 \n 获取换行符。

    例如,format:"The author of %h was %an, %ar%nThe title was >>%s<<%n" 将显示类似以下内容

    The author of fe6e0ee was Junio C Hamano, 23 hours ago
    The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

    占位符是

    • 扩展为单个字面字符的占位符

      %n

      换行符

      %%

      一个原始 %

      %x00

      %x 后面跟着两个十六进制数字将被替换为具有十六进制数字值的字节(在本文档的其余部分中,我们将其称为“字面格式代码”)。

    • 影响后面占位符格式的占位符

      %Cred

      将颜色切换为红色

      %Cgreen

      将颜色切换为绿色

      %Cblue

      将颜色切换为蓝色

      %Creset

      重置颜色

      %C(…​)

      颜色规范,如 git-config[1] 的“配置文

      %m

      左侧 (<)、右侧 (>) 或边界 (-) 标记

      %w([<w>[,<i1>[,<i2>]]])

      切换行换行,类似于 git-shortlog[1] 的 -w 选项。

      %<( <N> [,trunc|ltrunc|mtrunc])

      使下一个占位符至少占用 N 个列宽,如果必要,在右侧填充空格。如果输出超过 N 列,可以选择从左侧 (ltrunc) ..ft、中间 (mtrunc) mi..le 或结尾 (trunc) rig.. 处截断(带省略号 ..)。注意 1:截断仅在 N >= 2 时才能正常工作。注意 2:N 和 M(见下文)周围的空格是可选的。注意 3:表情符号和其他宽字符将占用两个显示列,这可能会超出列边界。注意 4:分解的字符组合标记可能在填充边界处位置错误。

      %<|( <M> )

      使下一个占位符至少占用直到第 M 个显示列,如果必要,在右侧填充空格。对于从终端窗口右侧边缘测量的列位置,使用负的 M 值。

      %>( <N> ), %>|( <M> )

      类似于 %<( <N> ), %<|( <M> ),但左侧填充空格

      %>>( <N> ), %>>|( <M> )

      类似于 %>( <N> ), %>|( <M> ),但如果下一个占位符占用的空格超过给定值,并且其左侧有空格,则使用这些空格

      %><( <N> ), %><|( <M> )

      类似于 %<( <N> ), %<|( <M> ),但双侧填充(即文本居中)

    • 扩展为从提交中提取的信息的占位符

      %H

      提交哈希

      %h

      缩写提交哈希

      %T

      树哈希

      %t

      缩写树哈希

      %P

      父哈希

      %p

      缩写父哈希

      %an

      作者姓名

      %aN

      作者姓名(尊重 .mailmap,参见 git-shortlog[1]git-blame[1])。

      %ae

      作者电子邮件

      %aE

      作者电子邮件(尊重 .mailmap,参见 git-shortlog[1]git-blame[1])。

      %al

      作者电子邮件本地部分(@ 符号之前的部分)

      %aL

      作者本地部分(参见 %al),尊重 .mailmap,参见 git-shortlog[1]git-blame[1])。

      %ad

      作者日期(格式尊重 --date= 选项)

      %aD

      作者日期,RFC2822 样式

      %ar

      作者日期,相对

      %at

      作者日期,UNIX 时间戳

      %ai

      作者日期,类似 ISO 8601 的格式

      %aI

      作者日期,严格的 ISO 8601 格式

      %as

      作者日期,简短格式 (YYYY-MM-DD)

      %ah

      作者日期,人性化风格(类似于 git-rev-list[1]--date=human 选项)。

      %cn

      提交者姓名

      %cN

      提交者姓名(尊重 .mailmap,参见 git-shortlog[1]git-blame[1])。

      %ce

      提交者电子邮件

      %cE

      提交者电子邮件(尊重 .mailmap,参见 git-shortlog[1]git-blame[1])。

      %cl

      提交者电子邮件本地部分(@ 符号之前的部分)

      %cL

      提交者本地部分(参见 %cl),尊重 .mailmap,参见 git-shortlog[1]git-blame[1])。

      %cd

      提交者日期(格式尊重 --date= 选项)

      %cD

      提交者日期,RFC2822 样式

      %cr

      提交者日期,相对

      %ct

      提交者日期,UNIX 时间戳

      %ci

      提交者日期,类似 ISO 8601 的格式

      %cI

      提交者日期,严格的 ISO 8601 格式

      %cs

      提交者日期,简短格式 (YYYY-MM-DD)

      %ch

      提交者日期,人性化风格(类似于 git-rev-list[1]--date=human 选项)。

      %d

      引用名称,类似于 git-log[1] 的 --decorate 选项

      %D

      引用名称,不带 " (", ")" 括号。

      %(decorate[:<options>])

      带自定义装饰的引用名称。decorate 字符串后面可以跟着冒号和零个或多个逗号分隔的选项。选项值可能包含字面格式代码。由于逗号 (%x2C) 和右括号 (%x29) 在选项语法中的作用,必须使用这些代码。

      • prefix=<value>:显示在引用名称列表之前。默认为 " ("。

      • suffix=<value>:显示在引用名称列表之后。默认为 ")"。

      • separator=<value>:显示在引用名称之间。默认为 ", "。

      • pointer=<value>:显示在 HEAD 和它指向的分支(如果有)之间。默认为 " -> "。

      • tag=<value>:显示在标签名称之前。默认为 "tag: "。

    例如,要生成没有包装或标签注释的装饰,并且以空格作为分隔符

    + %(decorate:prefix=,suffix=,tag=,separator= )

    %(describe[:<options>])

    人类可读的名称,类似于 git-describe[1];对于无法描述的提交,为空字符串。describe 字符串后面可以跟着冒号和零个或多个逗号分隔的选项。当标签同时添加或删除时,描述可能不一致。

    • tags[=<bool-value>]:除了只考虑带注释的标签之外,还考虑轻量级标签。

    • abbrev=<number>:不使用默认的十六进制数字数(根据存储库中对象的数目而变化,默认值为 7),而是使用 <number> 个数字,或者形成唯一对象名称所需的尽可能多的数字。

    • match=<pattern>:只考虑与给定 glob(7) 模式匹配的标签,排除 "refs/tags/" 前缀。

    • exclude=<pattern>:不要考虑与给定 glob(7) 模式匹配的标签,排除 "refs/tags/" 前缀。

    %S

    命令行上给出的引用名称,通过该名称到达提交(类似于 git log --source),仅适用于 git log

    %e

    编码

    %s

    主题

    %f

    经过清理的主题行,适合用作文件名

    %b

    正文

    %B

    原始主体(未包装的主题和主体)

    %N

    提交说明

    %GG

    来自 GPG 的原始验证消息,用于签署的提交

    %G?

    显示“G”表示良好(有效)签名,“B”表示错误签名,“U”表示有效签名但有效性未知,“X”表示已过期的有效签名,“Y”表示已过期的密钥生成的有效签名,“R”表示已吊销的密钥生成的有效签名,“E”表示签名无法检查(例如,缺少密钥),“N”表示没有签名

    %GS

    显示签署的提交的签名者姓名

    %GK

    显示用于签署签署的提交的密钥

    %GF

    显示用于签署签署的提交的密钥的指纹

    %GP

    显示用于签署签署的提交的子密钥的主密钥的指纹

    %GT

    显示用于签署签署的提交的密钥的信任级别

    %gD

    reflog 选择器,例如,refs/stash@{1}refs/stash@{2 minutes ago};格式遵循-g 选项中描述的规则。@ 之前的部分是命令行中给出的 refname(所以 git log -g refs/heads/master 会产生 refs/heads/master@{0})。

    %gd

    简化的 reflog 选择器;与 %gD 相同,但 refname 部分已简化以提高人类可读性(所以 refs/heads/master 仅变为 master)。

    %gn

    reflog 身份名称

    %gN

    reflog 身份名称(尊重 .mailmap,请参见 git-shortlog[1]git-blame[1]

    %ge

    reflog 身份电子邮件

    %gE

    reflog 身份电子邮件(尊重 .mailmap,请参见 git-shortlog[1]git-blame[1]

    %gs

    reflog 主题

    %(trailers[:<options>])

    显示由 git-interpret-trailers[1] 解释的主体后的尾部。trailers 字符串后面可以跟着冒号和零个或多个以逗号分隔的选项。如果提供多个选项,则最后一个出现的值为准。

    • key=<key>:仅显示具有指定 <key> 的尾部。匹配不区分大小写,尾部的冒号是可选的。如果多次给出选项,则显示匹配任何密钥的尾部行。此选项会自动启用 only 选项,以便隐藏尾部块中非尾部行。如果不需要,可以使用 only=false 禁用它。例如,%(trailers:key=Reviewed-by) 显示具有键 Reviewed-by 的尾部行。

    • only[=<bool>]:选择是否应包含来自尾部块的非尾部行。

    • separator=<sep>:指定插入在尾部行之间的分隔符。默认为换行符。字符串 <sep> 可以包含上面描述的文字格式代码。要使用逗号作为分隔符,必须使用 %x2C,否则它将被解析为下一个选项。例如,%(trailers:key=Ticket,separator=%x2C ) 显示所有键为“Ticket”的尾部行,以逗号和空格分隔。

    • unfold[=<bool>]:使它的行为类似于 interpret-trailer 的 --unfold 选项。例如,%(trailers:only,unfold=true) 展开并显示所有尾部行。

    • keyonly[=<bool>]:仅显示尾部的键部分。

    • valueonly[=<bool>]:仅显示尾部的值部分。

    • key_value_separator=<sep>:指定插入在每个尾部的键和值之间的分隔符。默认为“: ”。否则,它与上面的 separator=<sep> 具有相同的语义。

注意
某些占位符可能依赖于提供给修订遍历引擎的其他选项。例如,%g* reflog 选项将插入一个空字符串,除非我们正在遍历 reflog 条目(例如,通过 git log -g)。%d%D 占位符将使用“简短”装饰格式,除非命令行上已提供 --decorate

布尔选项接受一个可选的值 [=<bool-value>]。值 truefalseonoff 等都将被接受。请参见 git-config[1] 中“示例”中的“布尔值”子部分。如果布尔选项没有提供任何值,则它将被启用。

如果在占位符的 % 后添加一个 +(加号),则仅当占位符展开为非空字符串时,才会在展开之前插入换行符。

如果在占位符的 % 后添加一个 -(减号),则仅当占位符展开为空字符串时,才会删除紧接在展开之前的连续换行符。

如果在占位符的 % 后添加一个 ` `(空格),则仅当占位符展开为非空字符串时,才会在展开之前插入空格。

  • 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

差异格式

以下选项可用于更改 git show 生成差异输出的方式。

-p
-u
--patch

生成补丁(请参见 使用 -p 生成补丁文本)。

-s
--no-patch

抑制来自差异机制的所有输出。对诸如 git show 之类的默认情况下显示补丁的命令有用,以消除其输出,或者取消命令行中较早选项(如 --patch--stat)的效果,这些选项在别名中。

-m

以默认格式显示合并提交的差异。这类似于 --diff-merges=on,只是 -m 不会产生任何输出,除非也提供了 -p

-c

为合并提交生成组合差异输出。--diff-merges=combined -p 的简写。

--cc

为合并提交生成密集的组合差异输出。--diff-merges=dense-combined -p 的简写。

--dd

对合并提交和常规提交都生成相对于第一个父项的差异。--diff-merges=first-parent -p 的简写。

--remerge-diff

为合并提交生成重新合并差异输出。--diff-merges=remerge -p 的简写。

--no-diff-merges

--diff-merges=off 的同义词。

--diff-merges=<format>

指定用于合并提交的差异格式。默认值为 `dense-combined`,除非使用 --first-parent,在这种情况下,默认值为 first-parent

支持以下格式

off, none

禁用合并提交的差异输出。用于覆盖隐式值。

on, m

使合并提交的差异输出以默认格式显示。可以使用 log.diffMerges 配置变量更改默认格式,其默认值为 separate

first-parent, 1

显示相对于第一个父项的完整差异。这与 --patch 为非合并提交生成的格式相同。

separate

显示相对于每个父项的完整差异。为每个父项生成单独的日志条目和差异。

combined, c

同时显示从每个父项到合并结果的差异,而不是一次显示一个父项和结果之间的成对差异。此外,它只列出从所有父项修改的文件。

dense-combined, cc

通过省略内容在父项中只有两个变体且合并结果在未修改的情况下选择了其中一个的无趣的块,进一步压缩 --diff-merges=combined 生成的输出。

remerge, r

重新合并两个父项合并提交以创建一个临时树对象——可能包含带有冲突标记等的文件。然后显示该临时树与实际合并提交之间的差异。

使用此选项时发出的输出可能会发生变化,因此其与其他选项的交互也会发生变化(除非明确记录)。

--combined-all-paths

此标志会导致合并差异(用于合并提交)列出来自所有父项的文件的名称。因此,它仅在使用 --diff-merges=[dense-]combined 时才会生效,并且可能仅在检测到文件名更改时才有用(即,当请求了重命名或复制检测时)。

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

生成具有 <n> 行上下文而不是通常的 3 行的差异。暗示 --patch

--output=<file>

输出到特定文件而不是 stdout。

--output-indicator-new=<char>
--output-indicator-old=<char>
--output-indicator-context=<char>

指定用于指示生成的补丁中的新行、旧行或上下文行的字符。通常它们分别是 +- 和 ' '。

--raw

对于每个提交,使用原始差异格式显示更改摘要。请参见 git-diff[1] 中的“原始输出格式”部分。这与以原始格式显示日志本身不同,可以通过 --format=raw 实现。

--patch-with-raw

-p --raw 的同义词。

-t

显示差异输出中的树对象。

--indent-heuristic

启用将差异块边界移位的启发式方法,以使补丁更易于阅读。这是默认值。

--no-indent-heuristic

禁用缩进启发式方法。

--minimal

花更多时间确保生成最小的差异。

--patience

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

--histogram

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

--anchored=<text>

使用“锚定差异”算法生成差异。

此选项可以多次指定。

如果一行同时出现在源代码和目标代码中,只出现一次,并且以该文本开头,该算法尝试阻止该行在输出中显示为删除或添加。它在内部使用“patience diff”算法。

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

选择一个 diff 算法。变体如下

default, myers

基本的贪婪 diff 算法。目前,这是默认算法。

minimal

花更多时间确保生成最小的差异。

patience

在生成补丁时使用“patience diff”算法。

histogram

该算法扩展了 patience 算法,以“支持低出现频率的公共元素”。

例如,如果您将 diff.algorithm 变量配置为非默认值,并且想要使用默认值,则必须使用 --diff-algorithm=default 选项。

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

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

这些参数也可以使用 --stat-width=<width>--stat-name-width=<name-width>--stat-count=<count> 分别设置。

--compact-summary

输出扩展头信息(例如文件创建或删除(“new”或“gone”,如果它是符号链接,则可以选择 “+l”)和模式更改(“+x”或“-x”分别表示添加或删除可执行位))的简要摘要在 diffstat 中。信息放置在文件名部分和图形部分之间。暗示 --stat

--numstat

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

--shortstat

仅输出 --stat 格式的最后一行,其中包含修改的文件总数,以及添加和删除的总行数。

-X[<param1,param2,…​>]
--dirstat[=<param1,param2,…​>]

输出每个子目录更改的相对数量的分布。--dirstat 的行为可以通过向其传递以逗号分隔的参数列表来定制。默认值由 diff.dirstat 配置变量控制(参见 git-config[1])。以下参数可用

changes

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

lines

通过进行常规的基于行的 diff 分析,并将删除/添加的行数相加来计算 dirstat 数字。(对于二进制文件,改为计算 64 字节块,因为二进制文件没有自然的行概念)。这比 changes 行为更昂贵的 --dirstat 行为,但它将文件内重新排列的行计算为与其他更改一样多。生成的输出与您从其他 --*stat 选项获得的结果一致。

files

通过计算更改的文件数来计算 dirstat 数字。每个更改的文件在 dirstat 分析中都算作相等。这是计算成本最低的 --dirstat 行为,因为它根本不需要查看文件内容。

cumulative

也为父目录计算子目录中的更改。请注意,当使用 cumulative 时,报告的百分比总和可能会超过 100%。默认(非累积)行为可以使用 noncumulative 参数指定。

<limit>

一个整数参数指定一个截止百分比(默认值为 3%)。贡献小于此百分比更改的目录不会显示在输出中。

示例:以下将计算更改的文件,同时忽略更改文件总数的百分比小于 10% 的目录,并将子目录计数累积到父目录中:--dirstat=files,10,cumulative

--cumulative

与 --dirstat=cumulative 同义

--dirstat-by-file[=<param1,param2>…​]

与 --dirstat=files,<param1>,<param2>…​ 同义

--summary

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

--patch-with-stat

-p --stat 同义。

-z

用 NUL 而不是换行符分隔提交。

此外,当给出 --raw--numstat 时,不要混淆路径名,并使用 NUL 作为输出字段分隔符。

没有这个选项,路径名将用引号括起来,如配置变量 core.quotePath 所解释(参见 git-config[1])。

--name-only

仅显示后置图像树中每个更改文件的名称。文件名通常以 UTF-8 编码。有关更多信息,请参阅 git-log[1] 手册页中有关编码的讨论。

--name-status

仅显示每个更改文件的名称和状态。有关状态字母的含义,请参阅 --diff-filter 选项的说明。与 --name-only 一样,文件名通常以 UTF-8 编码。

--submodule[=<format>]

指定如何显示子模块中的差异。当指定 --submodule=short 时,将使用格式。此格式只显示范围开始和结束处的提交名称。当指定 --submodule--submodule=log 时,将使用日志格式。此格式像 git-submodule[1] summary 一样列出范围内的提交。当指定 --submodule=diff 时,将使用diff 格式。此格式显示提交范围之间子模块内容更改的内联 diff。默认为 diff.submodule,如果未设置配置选项,则默认为格式。

--color[=<when>]

显示彩色 diff。--color(即不带=<when>)与 --color=always 相同。<when> 可以是 alwaysneverauto 之一。

--no-color

关闭彩色 diff。它与 --color=never 相同。

--color-moved[=<mode>]

移动的代码行将以不同的颜色显示。如果未给出选项,则 <mode> 默认为no,如果给出没有模式的选项,则默认为zebra。模式必须是以下之一

no

移动的代码行不会突出显示。

default

zebra 的同义词。将来可能会更改为更合理的模式。

plain

任何在某处添加并在其他位置删除的代码行都将使用color.diff.newMoved 颜色显示。类似地,color.diff.oldMoved 将用于在 diff 中其他地方添加的删除代码行。此模式会拾取所有移动的代码行,但在代码评审中,它对于确定代码块是否在没有置换的情况下移动并不十分有用。

blocks

贪婪地检测到至少 20 个字母数字字符的移动文本块。检测到的块将使用color.diff.{old,new}Moved 颜色绘制。相邻块无法区分。

zebra

移动文本块的检测方式与blocks 模式相同。块将使用color.diff.{old,new}Moved 颜色或color.diff.{old,new}MovedAlternative 颜色绘制。两种颜色之间的变化表示检测到一个新块。

dimmed-zebra

类似于zebra,但对移动代码中不感兴趣的部分进行了额外的调暗处理。两个相邻块的边界线被认为是感兴趣的,其余部分是不感兴趣的。dimmed_zebra 是一个已弃用的同义词。

--no-color-moved

关闭移动检测。这可用于覆盖配置设置。它与 --color-moved=no 相同。

--color-moved-ws=<modes>

此选项配置在执行 --color-moved 的移动检测时如何忽略空白。这些模式可以以逗号分隔的列表形式给出

no

在执行移动检测时,不忽略空白。

ignore-space-at-eol

忽略行尾的空白变化。

ignore-space-change

忽略空白数量的变化。这会忽略行尾的空白,并将所有其他一个或多个空白字符的序列视为等效。

ignore-all-space

比较行时忽略空白。这会忽略差异,即使一行有空白而另一行没有。

allow-indentation-change

最初在移动检测中忽略任何空白,然后仅当每行空白变化相同的情况下,将移动的代码块分组到一个块中。这与其他模式不兼容。

--no-color-moved-ws

在执行移动检测时,不忽略空白。这可以用来覆盖配置设置。它与 --color-moved-ws=no 相同。

--word-diff[=<mode>]

显示词语差异,使用 <mode> 来界定变化的词语。默认情况下,词语由空白界定;请参见下面的 --word-diff-regex。<mode> 默认值为 plain,必须是以下之一:

color

仅使用颜色突出显示变化的词语。隐含 --color

plain

显示词语为 [-removed-]{+added+}。如果分隔符出现在输入中,则不尝试转义分隔符,因此输出可能不明确。

porcelain

使用专为脚本使用而设计的基于行的特殊格式。添加/删除/不变的运行以通常的统一差异格式打印,从行的开头开始一个 +/-/` ` 字符,并扩展到行的末尾。输入中的换行符用一个波浪号 ~ 在它自己的行上表示。

none

再次禁用词语差异。

请注意,尽管第一个模式的名称是“颜色”,但如果启用了颜色,则所有模式都会使用颜色来突出显示变化的部分。

--word-diff-regex=<regex>

使用 <regex> 来决定什么是词语,而不是将非空白字符的运行视为词语。除非 --word-diff 已经启用,否则也会隐含 --word-diff

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

例如,--word-diff-regex=. 将把每个字符视为一个词语,因此会逐个字符地显示差异。

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

--color-words[=<regex>]

等效于 --word-diff=color 加上(如果指定了正则表达式)--word-diff-regex=<regex>

--no-renames

关闭重命名检测,即使配置文件指定默认值也如此。

--[no-]rename-empty

是否使用空 Blob 作为重命名源。

--check

如果更改引入了冲突标记或空白错误,则发出警告。什么被认为是空白错误由 core.whitespace 配置控制。默认情况下,尾随空白(包括仅包含空白的行)以及紧跟在行首缩进内的制表符之前的空格字符被认为是空白错误。如果发现问题,则退出并返回非零状态。与 --exit-code 不兼容。

--ws-error-highlight=<kind>

突出显示差异中 contextoldnew 行中的空白错误。多个值用逗号分隔,none 重置先前值,default 将列表重置为 new,而 allold,new,context 的简写。当此选项未给出且配置变量 diff.wsErrorHighlight 未设置时,仅突出显示 new 行中的空白错误。空白错误使用 color.diff.whitespace 着色。

--full-index

在生成补丁格式输出时,不要显示前几个字符,而是在“索引”行上显示完整的预映像和后映像 Blob 对象名称。

--binary

除了 --full-index 之外,还会输出一个二进制差异,可以使用 git-apply 应用。隐含 --patch

--abbrev[=<n>]

在 diff-raw 格式输出和 diff-tree 标头行中,不要显示完整的 40 字节十六进制对象名称,而是显示最短的前缀,该前缀至少有 <n> 个十六进制数字,并且唯一地引用该对象。在 diff-patch 输出格式中,--full-index 优先级更高,即如果指定了 --full-index,无论 --abbrev 如何,都会显示完整的 Blob 名称。可以使用 --abbrev=<n> 指定非默认数字。

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

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

它会影响将完全重写文件视为一系列删除和插入(与极少数文本匹配的行混合在一起)而不是作为单个删除旧内容,然后是单个插入新内容的方式,并且数字 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 之间的差异。生成的补丁不适合用 patchgit apply 应用;这仅仅是为了那些只想专注于查看更改后的文本的人。此外,输出显然缺乏足够的信息来反向应用此类补丁,即使是手动操作,因此也是选项的名称。

当与 -B 一起使用时,也会省略删除/创建对中的删除部分的预映像。

-l<num>

-M-C 选项涉及一些初步步骤,可以廉价地检测重命名/复制的子集,然后是一个详尽的回退部分,将所有剩余的未配对目标与所有相关源进行比较。(对于重命名,仅剩余的未配对源是相关的;对于复制,所有原始源都是相关的。)对于 N 个源和目标,此详尽检查为 O(N^2)。如果涉及的源/目标文件数量超过指定数量,此选项将阻止重命名/复制检测的详尽部分运行。默认为 diff.renameLimit。请注意,值为 0 被视为无限制。

--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>之间的区别,请考虑一个在同一个文件中具有以下差异的提交。

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

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

除非提供--text,否则没有 textconv 过滤器的二进制文件的补丁将被忽略。

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

--find-object=<object-id>

查找更改指定对象出现次数的差异。类似于-S,只是参数不同,它不是搜索特定字符串,而是搜索特定对象 ID。

该对象可以是 blob 或子模块提交。它隐含了git-log 中的-t选项,以查找树。

--pickaxe-all

-S-G找到更改时,显示更改集中所有的更改,而不仅仅是包含<string>中更改的文件。

--pickaxe-regex

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

-O<orderfile>

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

输出顺序由<orderfile>中 glob 模式出现的顺序决定。所有路径名匹配第一个模式的文件首先输出,所有路径名匹配第二个模式(但不匹配第一个模式)的文件其次输出,依此类推。所有路径名不匹配任何模式的文件最后输出,就像文件末尾有一个隐式的匹配所有模式一样。如果多个路径名具有相同的等级(它们匹配同一个模式,但没有匹配更早的模式),它们之间的相对输出顺序是正常的顺序。

<orderfile>的解析方式如下:

  • 空行被忽略,因此它们可以作为分隔符以提高可读性。

  • 以哈希号(“#”)开头的行被忽略,因此它们可以用于注释。如果模式以哈希号开头,则在模式开头添加反斜杠(“\”)。

  • 每行包含一个模式。

模式与用于 fnmatch(3) 的模式具有相同的语法和语义,但没有 FNM_PATHNAME 标志,除非路径名也与模式匹配,如果删除任何数量的最终路径名组件与模式匹配。例如,模式“foo*bar”匹配“fooasdfbar”和“foo/bar/baz/asdf”,但不匹配“foobarx”。

--skip-to=<file>
--rotate-to=<file>

丢弃输出中名为<file>之前的文件(即跳到),或将它们移到输出的末尾(即旋转到)。这些选项最初是为git difftool命令的使用而设计的,在其他情况下可能不太有用。

-R

交换两个输入;也就是说,显示从索引或磁盘上的文件到树内容的差异。

--relative[=<path>]
--no-relative

从项目的子目录运行时,可以使用此选项告诉它排除目录之外的更改,并显示相对于它的路径名。当您不在子目录中(例如在裸仓库中)时,可以通过给出<path>作为参数来指定要使输出相对于哪个子目录。--no-relative可用于反驳diff.relative配置选项和之前的--relative

-a
--text

将所有文件视为文本。

--ignore-cr-at-eol

在进行比较时,忽略行尾的回车符。

--ignore-space-at-eol

忽略行尾的空白变化。

-b
--ignore-space-change

忽略空白数量的变化。这会忽略行尾的空白,并将所有其他一个或多个空白字符的序列视为等效。

-w
--ignore-all-space

比较行时忽略空白。这会忽略差异,即使一行有空白而另一行没有。

--ignore-blank-lines

忽略所有行都是空白的行更改。

-I<regex>
--ignore-matching-lines=<regex>

忽略所有行匹配<regex>的更改。此选项可以多次指定。

--inter-hunk-context=<lines>

显示 diff 块之间的上下文,最多指定行数,从而将彼此靠近的块融合在一起。默认为diff.interHunkContext,或者如果配置选项未设置,则为 0。

-W
--function-context

为每个更改显示整个函数作为上下文行。函数名称的确定方式与git diff确定补丁块头的机制相同(请参阅 gitattributes[5] 中的定义自定义块头)。

--ext-diff

允许执行外部 diff 助手。如果您使用 gitattributes[5] 设置了外部 diff 驱动程序,则需要在 git-log[1] 及其相关命令中使用此选项。

--no-ext-diff

不允许外部 diff 驱动程序。

--textconv
--no-textconv

允许(或禁止)在比较二进制文件时运行外部文本转换过滤器。有关详细信息,请参阅 gitattributes[5]。由于文本转换过滤器通常是单向转换,因此生成的 diff 适用于人类阅读,但不能应用。出于这个原因,文本转换过滤器默认情况下仅对 git-diff[1]git-log[1] 启用,但对 git-format-patch[1] 或 diff 管道命令不启用。

--ignore-submodules[=<when>]

在 diff 生成中忽略对子模块的更改。<when> 可以是“none”、“untracked”、“dirty”或“all”,默认为“all”。使用“none”将在子模块包含未跟踪或已修改的文件或其 HEAD 与超级项目中记录的提交不同时将子模块视为已修改,并且可用于覆盖 git-config[1]gitmodules[5]ignore选项的任何设置。当使用“untracked”时,如果子模块仅包含未跟踪的内容,则不认为子模块是脏的(但它们仍然会扫描已修改的内容)。使用“dirty”会忽略对子模块工作树的所有更改,只会显示对超级项目中存储的提交的更改(这是 1.7.0 之前的行为)。使用“all”会隐藏对子模块的所有更改。

--src-prefix=<prefix>

显示给定的源前缀,而不是“a/”。

--dst-prefix=<prefix>

显示给定的目标前缀,而不是“b/”。

--no-prefix

不显示任何源或目标前缀。

--default-prefix

使用默认的源和目标前缀(“a/”和“b/”。这将覆盖诸如diff.noprefixdiff.srcPrefixdiff.dstPrefixdiff.mnemonicPrefix之类的配置变量(请参阅git-config(1))。

--line-prefix=<prefix>

在输出的每一行前面添加一个额外的前缀。

--ita-invisible-in-index

默认情况下,由“git add -N”添加的条目在“git diff”中显示为现有的空文件,在“git diff --cached”中显示为新文件。此选项使该条目在“git diff”中显示为新文件,在“git diff --cached”中显示为不存在。此选项可以通过--ita-visible-in-index恢复。这两个选项都是实验性的,可能会在将来被移除。

有关这些常用选项的更详细说明,请参阅 gitdiffcore[7]

使用 -p 生成补丁文本

使用-p选项运行 git-diff[1]git-log[1]git-show[1]git-diff-index[1]git-diff-tree[1]git-diff-files[1] 会生成补丁文本。您可以通过GIT_EXTERNAL_DIFFGIT_DIFF_OPTS环境变量(请参阅 git[1])以及diff属性(请参阅 gitattributes[5])来自定义补丁文本的创建。

-p选项生成的输出与传统的 diff 格式略有不同

  1. 它前面有一个“git diff”标题,如下所示

    diff --git a/file1 b/file2

    除非涉及重命名/复制,否则a/b/文件名相同。特别地,即使是创建或删除,/dev/null也不会用在a/b/文件名的位置。

    当涉及重命名/复制时,file1file2分别显示重命名/复制的源文件名和重命名/复制生成的文件名。

  2. 它后面是一个或多个扩展标题行

    old mode <mode>
    new mode <mode>
    deleted file mode <mode>
    new file mode <mode>
    copy from <path>
    copy to <path>
    rename from <path>
    rename to <path>
    similarity index <number>
    dissimilarity index <number>
    index <hash>..<hash> <mode>

    文件模式以包含文件类型和文件权限位的 6 位八进制数字形式打印。

    扩展标题中的路径名不包括a/b/前缀。

    相似度指数是不变行的百分比,差异度指数是改变行的百分比。它是一个四舍五入的整数,后面跟着一个百分号。因此,100% 的相似度指数值用于两个相等的文件,而 100% 的差异度意味着旧文件中的任何行都没有出现在新文件中。

    索引行包括更改前后的 blob 对象名称。如果文件模式没有改变,则会包含<mode>;否则,单独的行会指示旧模式和新模式。

  3. 包含“不寻常”字符的路径名将按配置变量core.quotePath(请参阅 git-config[1])所述进行引用。

  4. 输出中的所有file1文件都指的是提交之前的文件,所有file2文件都指的是提交后的文件。将每个更改依次应用于每个文件是错误的。例如,此补丁将交换 a 和 b

    diff --git a/a b/b
    rename from a
    rename to b
    diff --git a/b b/a
    rename from b
    rename to a
  5. 块头会提及块所应用的函数的名称。有关如何针对特定语言调整此机制的详细信息,请参阅 gitattributes[5] 中的“定义自定义块头”。

组合 diff 格式

任何生成差异的命令都可以使用-c--cc选项,在显示合并时生成合并差异。这是使用git-diff[1]git-show[1]显示合并时的默认格式。另外请注意,您可以向这些命令中的任何一个提供合适的--diff-merges选项,以强制生成特定格式的差异。

"合并差异"格式如下所示

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);
  1. 它以一个“git diff”头开始,该头看起来像这样(当使用-c选项时)

    diff --combined file

    或者像这样(当使用--cc选项时)

    diff --cc file
  2. 它后面跟着一个或多个扩展头行(此示例显示了一个有两个父项的合并)

    index <hash>,<hash>..<hash>
    mode <mode>,<mode>..<mode>
    new file mode <mode>
    deleted file mode <mode>,<mode>

    mode <mode>,<mode>..<mode>行仅在至少一个<mode>与其他<mode>不同时出现。包含有关检测到的内容移动信息(重命名和复制检测)的扩展头旨在与两个<tree-ish>的差异一起使用,并且不被合并差异格式使用。

  3. 它后面跟着一个两行的from-file/to-file头

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

    类似于传统统一差异格式的两行头,/dev/null用于表示创建或删除的文件。

    但是,如果提供了--combined-all-paths选项,则您将获得一个N+1行的from-file/to-file头,而不是两行的from-file/to-file头,其中N是合并提交中的父项数量。

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

    如果重命名或复制检测处于活动状态,这种扩展格式可能很有用,因为它允许您查看文件中不同父项的原始名称。

  4. 块头格式已修改,以防止人们意外地将其提供给patch -p1。合并差异格式是为审查合并提交更改而创建的,而不是为了应用而设计的。这种更改类似于扩展索引头中的更改。

    @@@ <from-file-range> <from-file-range> <to-file-range> @@@

    合并差异格式的块头中包含(父项数量 + 1)个@字符。

与传统的统一差异格式不同,传统的统一差异格式显示了两个文件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是阶段2,即“我们的版本”,file2是阶段3,即“他们的版本”)。

示例

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

显示分支next的第10次上一次提交中文件Documentation/README的内容。

git show master:Makefile master:t/Makefile

连接分支master头部的这些Makefile的内容。

讨论

Git在某种程度上是字符编码无关的。

  • Blob对象的 内容是未解释的字节序列。核心级别没有编码转换。

  • 路径名使用UTF-8规范化形式C进行编码。这适用于树对象、索引文件、引用名,以及命令行参数、环境变量和配置文件(.git/config(见git-config[1])、gitignore[5]gitattributes[5]gitmodules[5])中的路径名。

    请注意,核心级别的 Git 将路径名简单地视为非空字节序列,没有路径名编码转换(除了 Mac 和 Windows 上)。因此,即使在使用传统扩展 ASCII 编码的平台和文件系统上,使用非 ASCII 路径名也会大部分正常工作。但是,在这些系统上创建的存储库在基于 UTF-8 的系统(例如 Linux、Mac、Windows)上将无法正常工作,反之亦然。此外,许多基于 Git 的工具只是假设路径名为 UTF-8,并且无法正确显示其他编码。

  • 提交日志消息通常使用 UTF-8 编码,但其他扩展 ASCII 编码也受支持。这包括 ISO-8859-x、CP125x 和许多其他编码,但不包括 UTF-16/32、EBCDIC 和 CJK 多字节编码(GBK、Shift-JIS、Big5、EUC-x、CP9xx 等)。

虽然我们鼓励提交日志消息使用 UTF-8 编码,但核心和 Git Porcelain 都被设计为不强迫项目使用 UTF-8。如果某个项目的参与者都发现使用传统编码更方便,Git 不会禁止这样做。但是,有一些事项需要注意。

  1. git commitgit commit-tree 会发出警告,如果提供的提交日志消息不像是有效的 UTF-8 字符串,除非您明确说明您的项目使用传统编码。说明这一点的方法是在.git/config文件中使用i18n.commitEncoding,如下所示

    [i18n]
    	commitEncoding = ISO-8859-1

    使用上述设置创建的提交对象在其encoding头中记录i18n.commitEncoding的值。这是为了帮助以后查看它们的人。缺少此头意味着提交日志消息使用 UTF-8 编码。

  2. git loggit showgit blame 及其同类工具会查看提交对象的encoding头,并尝试将日志消息重新编码为 UTF-8,除非另有说明。您可以使用.git/config文件中的i18n.logOutputEncoding指定所需的输出编码,如下所示

    [i18n]
    	logOutputEncoding = ISO-8859-1

    如果您没有此配置变量,则使用i18n.commitEncoding的值。

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

Git

git[1]套件的一部分

scroll-to-top