Git
English ▾ 主题 ▾ 最新版本 ▾ git-log 最后更新于 2.46.0

名称

git-log - 显示提交日志

概要

git log [<options>] [<revision-range>] [[--] <path>…​]

描述

显示提交日志。

列出通过遵循给定提交的parent链接可到达的提交，但排除从前面带有^的提交可到达的提交。默认情况下，输出按时间反向顺序给出。

您可以将其视为一个集合运算。从命令行上给定的任何提交可到达的提交形成一个集合，然后从前面带有^的任何提交可到达的提交从该集合中减去。剩余的提交是命令输出中出现的内容。各种其他选项和路径参数可用于进一步限制结果。

因此，以下命令

$ git log foo bar ^baz

表示“列出所有从foo或bar可到达但从baz不可到达的提交”。

特殊符号“<commit1>..<commit2>”可用作“^<commit1> <commit2>”的简写。例如，以下两者可以互换使用

$ git log origin..HEAD
$ git log HEAD ^origin

另一个特殊符号是“<commit1>…​<commit2>”，它对于合并很有用。生成的提交集是两个操作数之间的对称差。以下两个命令等效

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

该命令采用适用于git-rev-list[1]命令的选项来控制显示的内容和方式，以及适用于git-diff[1]命令的选项来控制如何显示每个提交引入的更改。

选项

--follow

在重命名后继续列出文件的历史记录（仅适用于单个文件）。

--no-decorate
--decorate[=short|full|auto|no]

打印显示的任何提交的 ref 名称。如果指定了short，则不会打印 ref 名称前缀refs/heads/、refs/tags/和refs/remotes/。如果指定了full，则将打印完整的 ref 名称（包括前缀）。如果指定了auto，则如果输出到终端，则 ref 名称将显示为如果给出了short一样，否则不显示 ref 名称。选项--decorate是--decorate=short的简写。如果已配置，则默认为log.decorate的配置值，否则为auto。

--decorate-refs=<pattern>
--decorate-refs-exclude=<pattern>

对于每个候选引用，如果它与传递给--decorate-refs-exclude的任何模式匹配，或者如果它与传递给--decorate-refs的任何模式都不匹配，则不要将其用于修饰。log.excludeDecoration配置选项允许从修饰中排除 ref，但显式--decorate-refs模式将覆盖log.excludeDecoration中的匹配项。

如果没有给出这些选项或配置设置，则如果引用与HEAD、refs/heads/、refs/remotes/、refs/stash/或refs/tags/匹配，则将其用作修饰。

--clear-decorations

当指定时，此选项将清除所有先前的--decorate-refs或--decorate-refs-exclude选项，并将默认修饰过滤器放宽以包括所有引用。如果配置值log.initialDecorationSet设置为all，则假定此选项。

--source

打印命令行上给出的每个提交所达到的 ref 名称。

--[no-]mailmap
--[no-]use-mailmap

使用 mailmap 文件将作者和提交者姓名和电子邮件地址映射到规范的真实姓名和电子邮件地址。参见git-shortlog[1]。

--full-diff

在没有此标志的情况下，git log -p <path>...显示接触指定路径的提交，以及关于相同指定路径的差异。使用此标志，将显示接触指定路径的提交的完整差异；这意味着“<path>…​”仅限制提交，而不限制这些提交的差异。

请注意，这会影响所有基于差异的输出类型，例如由--stat等生成的输出类型。

--log-size

在每个提交的输出中包含一行“log size <number>”，其中<number>是该提交消息的长度（以字节为单位）。旨在通过允许提前分配空间来加快从git log输出读取日志消息的工具的速度。

-L<start>,<end>:<file>
-L:<funcname>:<file>

跟踪在<file>中由<start>,<end>或函数名称正则表达式<funcname>给出的行范围的演变。您可能不会给出任何路径规范限制符。这目前仅限于从单个修订版开始的遍历，即，您只能给出零个或一个正修订版参数，并且<start>和<end>（或<funcname>）必须存在于起始修订版中。您可以多次指定此选项。意味着--patch。可以使用--no-patch抑制补丁输出，但其他差异格式（即--raw、--numstat、--shortstat、--dirstat、--summary、--name-only、--name-status、--check）目前尚未实现。

<start>和<end>可以采用以下其中一种形式

  • 数字

    如果<start>或<end>是数字，则它指定一个绝对行号（行从 1 开始计数）。

  • /正则表达式/

    此表单将使用与给定 POSIX 正则表达式匹配的第一行。如果<start>是正则表达式，它将从任何先前的-L范围的末尾开始搜索，否则从文件开头开始搜索。如果<start>是^/正则表达式/，它将从文件开头开始搜索。如果<end>是正则表达式，它将从<start>给出的行开始搜索。

  • +偏移量或-偏移量

    这仅对<end>有效，并将指定<start>给出的行之前或之后的行数。

如果在<start>和<end>的位置给出了:<funcname>，则它是一个正则表达式，表示从与<funcname>匹配的第一个 funcname 行到下一个 funcname 行的范围。:<funcname>从任何先前的-L范围的末尾开始搜索，否则从文件开头开始搜索。^:<funcname>从文件开头开始搜索。函数名称的确定方式与git diff确定补丁块标题的方式相同（请参阅gitattributes[5]中的定义自定义块标题）。

<revision-range>

仅显示指定修订版范围内的提交。当未指定<revision-range>时，它默认为HEAD（即导致当前提交的整个历史记录）。origin..HEAD指定所有可从当前提交（即HEAD）到达的提交，但不能从origin到达。有关拼写<revision-range>的完整列表，请参阅gitrevisions[7]的指定范围部分。

[--] <path>…​

仅显示足以解释与指定路径匹配的文件是如何产生的提交。有关详细信息和其他简化模式，请参阅下面的历史记录简化。

当出现混淆时，可能需要在路径前加上--以将其与选项或修订版范围分隔开。

提交限制

除了使用描述中解释的特殊符号指定要列出的提交范围外，还可以应用其他提交限制。

通常，使用更多选项会进一步限制输出（例如，--since=<date1> 限制为比 <date1> 新的提交，并且与 --grep=<pattern> 一起使用会进一步限制为日志消息包含与 <pattern> 匹配的行 的提交），除非另有说明。

请注意，这些选项在提交排序和格式化选项（如 --reverse）之前应用。

-<number>
-n <number>
--max-count=<number>

限制输出的提交数量。

--skip=<number>

在开始显示提交输出之前跳过 number 个提交。

--since=<date>
--after=<date>

显示比特定日期更新的提交。

--since-as-filter=<date>

显示所有比特定日期更新的提交。这会访问范围内的所有提交，而不是在第一个比特定日期旧的提交处停止。

--until=<date>
--before=<date>

显示比特定日期旧的提交。

--author=<pattern>
--committer=<pattern>

将提交输出限制为其作者/提交者头行与指定模式（正则表达式）匹配的提交。如果使用多个 --author=<pattern>，则选择其作者与任何给定模式匹配的提交（多个 --committer=<pattern> 类似）。

--grep-reflog=<pattern>

将提交输出限制为其 reflog 条目与指定模式（正则表达式）匹配的提交。如果使用多个 --grep-reflog，则选择其 reflog 消息与任何给定模式匹配的提交。除非正在使用 --walk-reflogs，否则使用此选项将导致错误。

--grep=<pattern>

将提交输出限制为其日志消息与指定模式（正则表达式）匹配的提交。如果使用多个 --grep=<pattern>，则选择其消息与任何给定模式匹配的提交（但请参阅 --all-match）。

当 --notes 生效时，来自注释的消息将被匹配，就像它是日志消息的一部分一样。

--all-match

将提交输出限制为与所有给定 --grep 匹配的提交，而不是至少与一个匹配的提交。

--invert-grep

将提交输出限制为其日志消息与使用 --grep=<pattern> 指定的模式不匹配的提交。

-i
--regexp-ignore-case

不考虑字母大小写匹配限制模式的正则表达式。

--basic-regexp

将限制模式视为基本正则表达式；这是默认设置。

-E
--extended-regexp

将限制模式视为扩展正则表达式，而不是默认的基本正则表达式。

-F
--fixed-strings

将限制模式视为固定字符串（不要将模式解释为正则表达式）。

-P
--perl-regexp

将限制模式视为与 Perl 兼容的正则表达式。

对这些类型的正则表达式的支持是一个可选的编译时依赖项。如果 Git 没有编译支持它们，则提供此选项会导致它终止。

--remove-empty

当给定路径从树中消失时停止。

--merges

仅打印合并提交。这与 --min-parents=2 完全相同。

--no-merges

不要打印具有多个父级的提交。这与 --max-parents=1 完全相同。

--min-parents=<number>
--max-parents=<number>
--no-min-parents
--no-max-parents

仅显示至少（或最多）具有该数量父级提交的提交。特别是，--max-parents=1 与 --no-merges 相同，--min-parents=2 与 --merges 相同。--max-parents=0 提供所有根提交，--min-parents=3 提供所有章鱼合并。

--no-min-parents 和 --no-max-parents 再次重置这些限制（为无限制）。等效形式为 --min-parents=0（任何提交都有 0 个或更多个父级）和 --max-parents=-1（负数表示无上限）。

--first-parent

在查找要包含的提交时，在看到合并提交时仅遵循第一个父级提交。此选项在查看特定主题分支的演变时可以提供更好的概述，因为合并到主题分支中往往只是为了不时调整到更新的上游，并且此选项允许您忽略由此类合并引入历史记录的各个提交。

此选项还会将合并提交的默认 diff 格式更改为 first-parent，有关详细信息，请参阅 --diff-merges=first-parent。

--exclude-first-parent-only

在查找要排除的提交（使用 ^）时，在看到合并提交时仅遵循第一个父级提交。这可以用于查找主题分支中从其与远程分支分歧点开始的更改集，因为任意合并可以是有效的主题分支更改。

--not

反转所有后续修订规范（直到下一个 --not）中 ^ 前缀（或缺少前缀）的含义。当在命令行上 --stdin 之前使用时，通过 stdin 传递的修订不会受到它的影响。相反，当通过标准输入传递时，命令行上传递的修订不会受到它的影响。

--all

假装 refs/ 中的所有 ref 以及 HEAD 都在命令行上列出为 <commit>。

--branches[=<pattern>]

假装 refs/heads 中的所有 ref 都在命令行上列出为 <commit>。如果给定 <pattern>，则将分支限制为与给定 shell 通配符匹配的分支。如果模式缺少 ?、* 或 [，则隐含末尾的 /*。

--tags[=<pattern>]

假装 refs/tags 中的所有 ref 都在命令行上列出为 <commit>。如果给定 <pattern>，则将标签限制为与给定 shell 通配符匹配的标签。如果模式缺少 ?、* 或 [，则隐含末尾的 /*。

--remotes[=<pattern>]

假装 refs/remotes 中的所有 ref 都在命令行上列出为 <commit>。如果给定 <pattern>，则将远程跟踪分支限制为与给定 shell 通配符匹配的分支。如果模式缺少 ?、* 或 [，则隐含末尾的 /*。

--glob=<glob-pattern>

假装所有与 shell 通配符 <glob-pattern> 匹配的 ref 都在命令行上列出为 <commit>。如果缺少，则会自动添加前导 refs/。如果模式缺少 ?、* 或 [，则隐含末尾的 /*。

--exclude=<glob-pattern>

不包含与 <glob-pattern> 匹配的 ref，否则下一个 --all、--branches、--tags、--remotes 或 --glob 会考虑这些 ref。此选项的重复会累积排除模式，直到下一个 --all、--branches、--tags、--remotes 或 --glob 选项（其他选项或参数不会清除累积的模式）。

当分别应用于 --branches、--tags 或 --remotes 时，给定的模式不应以 refs/heads、refs/tags 或 refs/remotes 开头，并且当应用于 --glob 或 --all 时，它们必须以 refs/ 开头。如果需要尾随 /*，则必须明确给出。

--exclude-hidden=[fetch|receive|uploadpack]

不包含会被 git-fetch、git-receive-pack 或 git-upload-pack 隐藏的 ref，方法是咨询相应的 fetch.hideRefs、receive.hideRefs 或 uploadpack.hideRefs 配置以及 transfer.hideRefs（请参阅 git-config[1]）。此选项会影响下一个伪 ref 选项 --all 或 --glob，并在处理完它们后清除。

--reflog

假装 reflog 中提到的所有对象都以 <commit> 的形式在命令行上列出。

--alternate-refs

假装所有作为备用存储库的 ref 顶端提到的对象都已在命令行上列出。备用存储库是其对象目录在 objects/info/alternates 中指定的任何存储库。包含的对象集可能会被 core.alternateRefsCommand 等修改。请参阅 git-config[1]。

--single-worktree

默认情况下，当有多个工作树时（请参阅 git-worktree[1]），以下选项将检查所有工作树：--all、--reflog 和 --indexed-objects。此选项强制它们仅检查当前工作树。

--ignore-missing

在输入中看到无效的对象名称时，假装没有给出错误的输入。

--bisect

假设错误的二分查找引用refs/bisect/bad已列出，并且后面跟着命令行上的--not和正确的二分查找引用refs/bisect/good-*。

--stdin

除了从命令行获取参数外，还可以从标准输入读取参数。这接受提交和伪选项，如--all和--glob=。当看到--分隔符时，以下输入将被视为路径并用于限制结果。通过标准输入读取的标志（如--not）仅在其以相同方式传递的参数中受尊重，并且不会影响任何后续的命令行参数。

--cherry-mark

类似于--cherry-pick（见下文），但用=标记等效的提交，而不是省略它们，用+标记不等效的提交。

--cherry-pick

当使用对称差集限制提交集时，省略任何引入与“另一侧”上的其他提交相同更改的提交。

例如，如果您有两个分支，A和B，列出它们一侧的所有提交的一种常用方法是使用--left-right（请参阅下面--left-right选项说明中的示例）。但是，它会显示从另一个分支中 cherry-pick 的提交（例如，“b 上的第 3 个”可能是从分支 A 中 cherry-pick 的）。使用此选项，此类提交对将从输出中排除。

--left-only
--right-only

仅列出对称差集各自侧面的提交，即仅列出--left-right将标记为<或>的那些提交。

例如，--cherry-pick --right-only A...B会省略B中存在于A中或与A中的提交补丁等效的那些提交。换句话说，这列出了git cherry A B中的+提交。更准确地说，--cherry-pick --right-only --no-merges提供了准确的列表。

--cherry

--right-only --cherry-mark --no-merges的同义词；用于将输出限制在我们这一侧的提交，并标记已应用于分叉历史另一侧的提交（使用git log --cherry upstream...mybranch），类似于git cherry upstream mybranch。

-g
--walk-reflogs

不遍历提交祖先链，而是从最新的 reflog 条目遍历到较旧的条目。使用此选项时，您无法指定要排除的提交（即，不能使用^commit、commit1..commit2和commit1...commit2表示法）。

使用除oneline和reference之外的--pretty格式（出于显而易见的原因），这会导致输出包含从 reflog 中获取的两行额外信息。输出中的 reflog 指定符可以显示为ref@{<Nth>}（其中<Nth>是 reflog 中的反时间顺序索引）或ref@{<timestamp>}（使用该条目的<timestamp>），具体取决于一些规则

  1. 如果起始点指定为ref@{<Nth>}，则显示索引格式。

  2. 如果起始点指定为ref@{now}，则显示时间戳格式。

  3. 如果两者均未使用，但命令行上给出了--date，则以--date请求的格式显示时间戳。

  4. 否则，显示索引格式。

在--pretty=oneline下，提交消息在同一行上以此信息为前缀。此选项不能与--reverse组合使用。另请参阅git-reflog[1]。

在--pretty=reference下，此信息将完全不会显示。

--merge

显示在范围HEAD...<other>中触及冲突路径的提交，其中<other>是MERGE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD或REBASE_HEAD中第一个存在的伪引用。仅当索引具有未合并的条目时才有效。此选项可用于在解决来自三方合并的冲突时显示相关提交。

--boundary

输出排除的边界提交。边界提交以-为前缀。

历史简化

有时您只对历史的某些部分感兴趣，例如修改特定<path>的提交。但是，历史简化有两个部分，一部分是选择提交，另一部分是如何执行它，因为有各种策略可以简化历史。

以下选项选择要显示的提交

<paths>

选择修改给定<paths>的提交。

--simplify-by-decoration

选择一些分支或标签引用的提交。

请注意，可以显示额外的提交以提供有意义的历史记录。

以下选项会影响执行简化的方式

默认模式

将历史简化为解释树最终状态的最简单历史。最简单，因为它如果最终结果相同（即合并具有相同内容的分支）则会修剪一些分支。

--show-pulls

包含默认模式中的所有提交，以及任何与第一个父级不为 TREESAME 但与后续父级为 TREESAME 的合并提交。此模式有助于显示“首次引入”分支更改的合并提交。

--full-history

与默认模式相同，但不会修剪一些历史记录。

--dense

仅显示选定的提交，以及一些用于创建有意义历史记录的提交。

--sparse

显示简化历史记录中的所有提交。

--simplify-merges

--full-history的附加选项，用于从结果历史中删除一些不必要的合并，因为没有选定的提交有助于此合并。

--ancestry-path[=<commit>]

当指定要显示的提交范围（例如commit1..commit2或commit2 ^commit1）时，仅显示该范围内是<commit>的祖先、<commit>的后代或<commit>本身的提交。如果未指定提交，则使用commit1（范围的排除部分）作为<commit>。可以多次传递；如果是这样，如果提交是给定的任何提交，或者它是其中一个提交的祖先或后代，则包含该提交。

以下是更详细的说明。

假设您将foo指定为<paths>。我们将修改foo的提交称为!TREESAME，其余的称为TREESAME。（在为foo过滤的差异中，它们分别看起来不同和相等。）

在下文中，我们将始终参考相同的示例历史记录来说明简化设置之间的差异。我们假设您正在此提交图中过滤文件foo

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

历史A---Q的水平线被视为每个合并的第一个父级。提交是

  • I是初始提交，其中foo包含内容“asdf”，并且文件quux包含内容“quux”。初始提交与空树进行比较，因此I为!TREESAME。

  • 在A中，foo仅包含“foo”。

  • B包含与A相同的更改。它的合并M是微不足道的，因此对所有父级都是TREESAME。

  • C不更改foo，但其合并N将其更改为“foobar”，因此它对任何父级都不是TREESAME。

  • D将foo设置为“baz”。它的合并O将N和D中的字符串组合为“foobarbaz”；即，它对任何父级都不是TREESAME。

  • E将quux更改为“xyzzy”，其合并P将字符串组合为“quux xyzzy”。P对O是TREESAME，但对E不是。

  • X是一个独立的根提交，它添加了一个新文件side，并且Y修改了它。Y对X是TREESAME。它的合并Q将side添加到P中，并且Q对P是TREESAME，但对Y不是。

rev-list向后遍历历史记录，根据是否使用--full-history和/或父级重写（通过--parents或--children）来包含或排除提交。以下设置可用。

默认模式

如果提交对任何父级都不是TREESAME，则包含该提交（尽管这可以更改，请参见下面的--sparse）。如果提交是合并提交，并且对一个父级是TREESAME，则仅遵循该父级。（即使有多个TREESAME父级，也只遵循其中一个。）否则，遵循所有父级。

这将导致

	  .-A---N---O
	 /     /   /
	I---------D

请注意，仅遵循TREESAME父级的规则如何完全删除了B。通过N考虑了C，但它是TREESAME。根提交与空树进行比较，因此I为!TREESAME。

父/子关系仅在使用--parents时可见，但这不会影响默认模式下选择的提交，因此我们显示了父级行。

--full-history不带父级重写

此模式与默认模式在一个点上有所不同：始终遵循合并的所有父级，即使它对其中一个父级是TREESAME。即使合并的多个方面都有包含的提交，但这并不意味着合并本身是!在示例中，我们得到

	I  A  B  N  D  O  P  Q

M被排除在外，因为它对两个父级都是TREESAME。E、C和B都被遍历，但只有B是!TREESAME，因此其他提交不会出现。

请注意，如果不进行父级重写，实际上不可能讨论提交之间的父/子关系，因此我们将它们显示为断开的。

--full-history带父级重写

仅当普通提交为!TREESAME时才包含它们（尽管这可以更改，请参见下面的--sparse）。

始终包含合并。但是，它们的父级列表被重写：沿着每个父级，修剪掉本身未包含的提交。这将导致

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

与不重写父提交的 --full-history 进行比较。请注意，E 被修剪掉了，因为它与树相同 (TREESAME)，但 P 的父提交列表被重写为包含 E 的父提交 I。C 和 N，以及 X、Y 和 Q 也是如此。

除了上述设置之外，还可以更改 TREESAME 是否影响包含关系。

--dense

如果遍历的提交与任何父提交都不相同 (TREESAME)，则将其包含在内。

--sparse

包含所有遍历的提交。

请注意，如果没有 --full-history，这仍然可以简化合并：如果其中一个父提交与树相同 (TREESAME)，我们只跟随那个父提交，因此永远不会遍历合并的另一侧。

--simplify-merges

首先，以与具有父提交重写功能的 --full-history 相同的方式构建历史图（见上文）。

然后根据以下规则将每个提交 C 简化为其在最终历史记录中的替换 C'

  • 将 C' 设置为 C。

  • 将 C' 的每个父提交 P 替换为其简化后的版本 P'。在此过程中，删除作为其他父提交的祖先或与空树相同的根提交的父提交，并删除重复项，但要注意永远不要删除所有与树相同的父提交。

  • 如果经过此父提交重写后，C' 是根提交或合并提交（具有零个或多个父提交）、边界提交或不与树相同 (TREESAME)，则它将保留。否则，它将被其唯一的父提交替换。

通过与具有父提交重写的 --full-history 进行比较，可以最好地说明其效果。示例变为

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

请注意 N、P 和 Q 与 --full-history 的主要区别。

  • N 的父提交列表中已删除 I，因为它 是另一个父提交 M 的祖先。尽管如此，N 仍然保留，因为它不与树相同 (TREESAME)。

  • P 的父提交列表也类似地删除了 I。然后完全删除了 P，因为它只有一个父提交并且与树相同 (TREESAME)。

  • Q 的父提交列表已将 Y 简化为 X。然后删除了 X，因为它是一个与树相同的根提交。然后完全删除了 Q，因为它只有一个父提交并且与树相同 (TREESAME)。

还有另一种简化模式可用。

--ancestry-path[=<commit>]

将显示的提交限制为 <commit> 的祖先，或 <commit> 的后代，或 <commit> 本身。

例如，考虑以下提交历史记录

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

常规的 D..M 计算 M 的祖先提交集，但排除 D 的祖先提交。这有助于了解自 D 以来导致 M 的历史记录发生了什么变化，从“M 有什么 D 中不存在的东西”的角度来看。在本例中，结果将是所有提交，除了 A 和 B（当然还有 D 本身）。

但是，当我们想要找出 M 中哪些提交受到 D 引入的错误的影响并需要修复时，我们可能希望仅查看 D..M 的子集，这些子集实际上是 D 的后代，即排除 C 和 K。这正是 --ancestry-path 选项的作用。应用于 D..M 范围时，其结果为

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

我们还可以使用 --ancestry-path=D 而不是 --ancestry-path，当应用于 D..M 范围时，它们的含义相同，但更明确。

如果我们改为对该范围内给定的主题感兴趣，以及受该主题影响的所有提交，我们可能只想查看 D..M 的子集，这些子集在其祖先路径中包含该主题。因此，例如，使用 --ancestry-path=H D..M 将导致

		E
		 \
		  G---H---I---J
			       \
				L--M

而 --ancestry-path=K D..M 将导致

		K---------------L--M

在讨论另一个选项 --show-pulls 之前，我们需要创建一个新的示例历史记录。

用户在查看简化后的历史记录时会遇到一个常见问题，即他们知道以某种方式更改了某个文件的提交未出现在该文件的简化历史记录中。让我们演示一个新示例，并展示在这种情况下 --full-history 和 --simplify-merges 等选项是如何工作的。

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

对于此示例，假设 I 创建了 file.txt，该文件以不同的方式被 A、B 和 X 修改。单亲提交 C、Z 和 Y 不会更改 file.txt。合并提交 M 是通过解决合并冲突以包含来自 A 和 B 的更改而创建的，因此与两者都不相同 (TREESAME)。但是，合并提交 R 是通过忽略 M 处 file.txt 的内容并仅采用 file.txt 在 X 处的内容而创建的。因此，R 与 X 相同 (TREESAME)，但与 M 不相同。最后，创建 N 的自然合并解决方案是采用 file.txt 在 R 处的内容，因此 N 与 R 相同 (TREESAME)，但与 C 不相同。合并提交 O 和 P 与其第一个父提交相同 (TREESAME)，但与第二个父提交 Z 和 Y 分别不相同。

在使用默认模式时，N 和 R 都有一个与树相同的父提交 (TREESAME)，因此会遍历这些边，而忽略其他边。生成的图如下

	I---X

在使用 --full-history 时，Git 会遍历每一条边。这将发现提交 A 和 B 以及合并 M，但也将揭示合并提交 O 和 P。使用父提交重写，生成的图如下

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

在这里，合并提交 O 和 P 产生了额外的噪音，因为它们实际上并没有对 file.txt 进行更改。它们只是合并了一个基于 file.txt 旧版本的主题。这在使用许多贡献者并行工作并在单个主干上合并其主题分支的工作流的存储库中是一个常见问题：许多不相关的合并出现在 --full-history 结果中。

在使用 --simplify-merges 选项时，提交 O 和 P 会从结果中消失。这是因为 O 和 P 的重写后的第二个父提交可以通过其第一个父提交访问。这些边将被删除，然后提交看起来像与父提交相同的单亲提交。这也发生在提交 N 上，从而导致如下所示的历史视图

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

在此视图中，我们看到了来自 A、B 和 X 的所有重要的单亲更改。我们还看到了精心解决的合并 M 和不太精心解决的合并 R。这通常足以确定为什么提交 A 和 B 在默认视图中“消失了”。但是，这种方法也存在一些问题。

第一个问题是性能。与任何以前的选项不同，--simplify-merges 选项需要遍历整个提交历史记录才能返回单个结果。这可能使该选项难以用于非常大的存储库。

第二个问题是审计问题。当许多贡献者在同一个存储库上工作时，重要的是哪些合并提交将更改引入重要分支。上面有问题的合并 R 不太可能是用于合并到重要分支的合并提交。相反，合并 N 用于将 R 和 X 合并到重要分支中。此提交可能在其提交消息中包含有关更改 X 为什么会覆盖来自 A 和 B 的更改的信息。

--show-pulls

除了默认历史记录中显示的提交之外，还显示每个与第一个父提交不相同 (TREESAME) 但与后续父提交相同的合并提交。

当 --show-pulls 包含合并提交时，该合并将被视为从另一个分支“拉取”更改。在此示例（以及没有其他选项）上使用 --show-pulls 时，生成的图如下

	I---X---R---N

在这里，合并提交 R 和 N 被包含在内，因为它们分别将提交 X 和 R 拉入基本分支。这些合并是提交 A 和 B 未出现在默认历史记录中的原因。

当 --show-pulls 与 --simplify-merges 配合使用时，该图将包含所有必要的信息。

	  .-A---M--.   N
	 /     /    \ /
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

请注意，由于 M 可以从 R 访问，因此从 N 到 M 的边被简化掉了。但是，N 仍然出现在历史记录中，因为它是一个重要的提交，因为它将更改 R “拉取”到主分支中。

--simplify-by-decoration 选项允许你仅查看历史记录拓扑的大图，方法是省略未被标签引用的提交。如果 (1) 它们被标签引用，或 (2) 它们更改了命令行上给定路径的内容，则提交将被标记为 !TREESAME（换句话说，在上述历史简化规则之后保留）。所有其他提交都被标记为 TREESAME（可能会被简化掉）。

提交顺序

默认情况下，提交按时间反向顺序显示。

--date-order

在显示所有子提交之前不显示父提交，但在其他情况下按提交时间戳顺序显示提交。

--author-date-order

在显示所有子提交之前不显示父提交，但在其他情况下按作者时间戳顺序显示提交。

--topo-order

在显示所有子提交之前不显示父提交，并避免在历史记录的多行上显示混合的提交。

例如，在如下所示的提交历史记录中

    ---1----2----4----7
	\	       \
	 3----5----6----8---

其中数字表示提交时间戳的顺序，带有 --date-order 的 git rev-list 及其相关命令将按时间戳顺序显示提交：8 7 6 5 4 3 2 1。

使用 --topo-order，它们将显示 8 6 5 3 7 4 2 1（或 8 7 4 2 6 5 3 1）；为了避免显示来自两个并行开发轨道的提交混合在一起，一些较旧的提交会在较新的提交之前显示。

--reverse

以相反的顺序输出选定的提交（请参见上面的“提交限制”部分）。不能与 --walk-reflogs 结合使用。

对象遍历

这些选项主要针对 Git 存储库的打包。

--no-walk[=(sorted|unsorted)]

仅显示给定的提交，但不遍历其祖先。如果指定了范围，则此选项无效。如果给出参数unsorted，则提交按命令行上给出的顺序显示。否则（如果给出sorted或未给出参数），则提交按提交时间以逆时间顺序显示。不能与--graph组合使用。

--do-walk

覆盖之前的--no-walk。

提交格式化

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

以给定格式漂亮打印提交日志的内容，其中<format>可以是oneline、short、medium、full、fuller、reference、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输出，我们将逐字输出该对象；这意味着原始提交中的无效序列可能会复制到输出中。同样，如果iconv(3)无法转换提交，我们将静默地逐字输出原始对象。

--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[=<ref>]

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

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

使用可选的<ref>参数，使用该引用查找要显示的注释。当引用以refs/notes/开头时，它可以指定完整的引用名称；当它以notes/开头时，refs/以及其他refs/notes/作为前缀来形成引用的完整名称。

可以组合多个--notes选项来控制显示哪些注释。例如：“--notes=foo”将仅显示来自“refs/notes/foo”的注释；“--notes=foo --notes”将显示来自“refs/notes/foo”和默认注释引用(s)的注释。

--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来检查签名提交对象的有效性，并显示输出。

--relative-date

--date=relative的同义词。

--date=<format>

仅对以人类可读格式显示的日期有效，例如在使用--pretty时。log.date配置变量为log命令的--date选项设置默认值。默认情况下，日期以原始时区（提交者或作者的时区）显示。如果-local附加到格式（例如，iso-local），则使用用户本地时区。

--date=relative显示相对于当前时间的日期，例如“2小时前”。-local选项对--date=relative无效。

--date=local是--date=default-local的别名。

--date=iso（或--date=iso8601）以类似ISO 8601的格式显示时间戳。与严格的ISO 8601格式的区别在于

  • 使用空格而不是T日期/时间分隔符

  • 时间和时区之间有一个空格

  • 时区的小时和分钟之间没有冒号

--date=iso-strict（或--date=iso8601-strict）以严格的ISO 8601格式显示时间戳。

--date=rfc（或--date=rfc2822）以RFC 2822格式显示时间戳，通常在电子邮件中找到。

--date=short仅显示日期，而不显示时间，格式为YYYY-MM-DD。

--date=raw显示自纪元（1970-01-01 00:00:00 UTC）以来的秒数，后跟一个空格，然后是相对于UTC的时区偏移量（一个+或-，后跟四位数字；前两位是小时，后两位是分钟）。即，就像时间戳是用strftime("%s %z")格式化一样）。请注意，-local选项不影响自纪元以来的秒数值（始终以UTC测量），但会切换附带的时区值。

--date=human如果时区与当前时区不匹配，则显示时区，如果匹配则不打印整个日期（即，对于“今年”的日期跳过打印年份，如果日期在过去几天内并且我们可以简单地说出它是星期几，则跳过整个日期本身）。对于较旧的日期，还会省略小时和分钟。

--date=unix显示日期作为Unix纪元时间戳（自1970年以来的秒数）。与--raw一样，这始终以UTC为单位，因此-local无效。

--date=format:...将格式...馈送到您的系统strftime，除了%s、%z和%Z，这些是在内部处理的。使用--date=format:%c以系统区域设置的首选格式显示日期。有关格式占位符的完整列表，请参阅strftime手册。使用-local时，正确的语法是--date=format-local:...。

--date=default是默认格式，基于ctime(3)输出。它显示一行，其中包含星期几的三字母缩写、月份的三字母缩写、日期、格式为“HH:MM:SS”的小时-分钟-秒，后跟四位数的年份，以及时区信息，除非使用本地时区，例如Thu Jan 1 00:00:00 1970 +0000。

--parents

还打印提交的父级（格式为“commit parent…​”）。还启用父级重写，请参阅上面的“历史简化”。

--children

还打印提交的子级（格式为“commit child…​”）。还启用父级重写，请参阅上面的“历史简化”。

--left-right

标记提交可以从哪个对称差异的一侧到达。左侧的提交以<为前缀，右侧的提交以>为前缀。如果与--boundary组合，则这些提交以-为前缀。

例如，如果您有以下拓扑结构

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

您将获得如下输出

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3rd on b
	>bbbbbbb... 2nd on b
	<aaaaaaa... 3rd on a
	<aaaaaaa... 2nd on a
	-yyyyyyy... 1st on b
	-xxxxxxx... 1st on a
--graph

在输出的左侧绘制提交历史的基于文本的图形表示。这可能会导致在提交之间打印额外的行，以便正确绘制图形历史。不能与--no-walk组合使用。

这会启用父级重写，请参阅上面的“历史简化”。

默认情况下，这意味着--topo-order选项，但也可以指定--date-order选项。

--show-linear-break[=<barrier>]

当不使用--graph时，所有历史分支都将被展平，这可能难以看出两个连续的提交是否属于线性分支。在这种情况下，此选项会在它们之间设置一个屏障。如果指定了<barrier>，则它将是显示的字符串，而不是默认字符串。

PRETTY FORMATS

如果提交是一个合并提交，并且 pretty-format 不是 oneline、email 或 raw，则在 Author: 行之前插入一个额外的行。此行以 "Merge: " 开头，并打印祖先提交的哈希值，用空格分隔。请注意，如果您限制了历史记录的查看范围，例如只对某个目录或文件的更改感兴趣，则列出的提交可能不一定是**直接**父提交的列表。

Git 提供了一些内置的格式，您还可以通过设置 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 信息显示真实的父提交，而不会考虑移植或历史简化。请注意，此格式会影响提交的显示方式，但不会影响差异的显示方式，例如使用 git log --raw。要在原始差异格式中获取完整的对象名称，请使用 --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] 的“配置文件”部分的“值”中所述。默认情况下，仅在为日志输出启用颜色时才会显示颜色（由 color.diff、color.ui 或 --color 启用，并尊重前者的 auto 设置，如果我们要输出到终端）。%C(auto,...) 作为默认值的旧版同义词被接受（例如，%C(auto,red)）。指定 %C(always,...) 将即使在未启用颜色时也会显示颜色（但请考虑仅使用 --color=always 来启用整个输出的颜色，包括此格式和 git 可能着色的任何其他内容）。单独使用 auto（即 %C(auto)）将在下一个占位符上启用自动着色，直到再次切换颜色。

      %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>])

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

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

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

      • separator=<value>：显示在 ref 名称之间。默认为 ", ".

      • 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

    命令行上给出的 ref 名称，通过该名称到达提交（如 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> 共享相同的语义。

注意
 某些占位符可能取决于提供给修订遍历引擎的其他选项。例如，除非我们正在遍历 reflog 条目（例如，通过 git log -g），否则 %g* reflog 选项将插入空字符串。如果命令行上未提供 --decorate，则 %d 和 %D 占位符将使用“短”修饰格式。

布尔选项接受可选值 [=<bool-value>]。true、false、on、off 等值都可接受。请参阅 git-config[1] 中“EXAMPLES”中的“boolean”子部分。如果布尔选项给出但没有值，则启用它。

如果在占位符的 % 后添加 +（加号），则当且仅当占位符扩展到非空字符串时，会在扩展之前立即插入换行符。

如果在占位符的 % 后添加 -（减号），则当且仅当占位符扩展为空字符串时，会删除紧接在扩展之前的连续换行符。

如果在占位符的 % 后添加 ` `（空格），则当且仅当占位符扩展到非空字符串时，会在扩展之前立即插入空格。

  • 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 log 不会生成任何差异输出。以下选项可用于显示每个提交所做的更改。

请注意，除非显式给出 --diff-merges 变体（包括短选项 -m、-c、--cc 和 --dd），否则合并提交将不会显示差异，即使选择了 --patch 等差异格式，也不会匹配 -S 等搜索选项。例外情况是使用 --first-parent 时，在这种情况下，first-parent 是合并提交的默认格式。

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

指定用于合并提交的差异格式。默认为 `off`，除非使用 --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>行上下文而不是通常的三行的差异。暗示--patch。

--output=<file>

输出到特定文件而不是标准输出。

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

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

--raw

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

--patch-with-raw

-p --raw的同义词。

-t

在 diff 输出中显示树对象。

--indent-heuristic

启用启发式方法，该方法会移动 diff 代码块边界以使补丁更易于阅读。这是默认设置。

--no-indent-heuristic

禁用缩进启发式。

--minimal

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

--patience

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

--histogram

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

--anchored=<text>

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

此选项可以指定多次。

如果一行同时存在于源和目标中，仅存在一次，并且以该文本开头，则此算法尝试防止它在输出中显示为删除或添加。它在内部使用“耐心 diff”算法。

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

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

default, myers

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

minimal

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

patience

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

histogram

此算法扩展了耐心算法以“支持低出现率的公共元素”。

例如，如果您将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.statNameWidth或diff.statGraphWidth不会影响git format-patch。通过给出第三个参数<count>，您可以将输出限制为前<count>行，如果还有更多行，则后跟...。

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

--compact-summary

输出扩展标题信息的简要摘要，例如文件创建或删除（“new”或“gone”，如果它是符号链接，则可选“+l”）以及模式更改（分别为“+x”或“-x”以添加或删除可执行位）。信息放在文件名部分和图形部分之间。暗示--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>]

显示彩色差异。--color（即不带=<when>）等同于--color=always。<when> 可以是 always、never 或 auto 之一。

--no-color

关闭彩色差异。等同于--color=never。

--color-moved[=<mode>]

移动的代码行将以不同的颜色显示。如果未指定该选项，则<mode>默认为no，如果指定该选项但不带模式，则默认为zebra。模式必须为以下之一：

no

不突出显示移动的行。

default

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

plain

在某个位置添加并在另一个位置删除的任何行都将使用color.diff.newMoved颜色显示。类似地，color.diff.oldMoved将用于在差异中其他位置添加的已删除行。此模式拾取任何移动的行，但在审查中确定代码块是否已移动且未进行排列方面并不是很有用。

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。

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

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

--full-index

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

--binary

除了--full-index之外，还会输出可以使用git-apply应用的二进制差异。暗示--patch。

--abbrev[=<n>]

在差异原始格式输出和差异树标题行中，不显示完整的 40 字节十六进制对象名称，而是显示至少长<n>个十六进制数字的、唯一引用该对象的最小前缀。在差异补丁输出格式中，--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 之间的差异。生成的补丁不适用于 patch 或 git 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.interHunkContext 或 0（如果未设置配置选项）。

-W
--function-context

为每个更改显示整个函数作为上下文行。函数名称的确定方式与 git diff 计算补丁块标头的方式相同（请参阅 gitattributes[5] 中的“定义自定义块标头”）。

--ext-diff

允许执行外部差异辅助程序。如果您使用 gitattributes[5] 设置了外部差异驱动程序，则需要将此选项与 git-log[1] 及其关联命令一起使用。

--no-ext-diff

禁止外部差异驱动程序。

--textconv
--no-textconv

允许（或不允许）在比较二进制文件时运行外部文本转换过滤器。有关详细信息，请参阅 gitattributes[5]。由于 textconv 过滤器通常是单向转换，因此生成的差异适合人工阅读，但无法应用。出于此原因，textconv 过滤器默认情况下仅对 git-diff[1] 和 git-log[1] 启用，而不对 git-format-patch[1] 或差异管道命令启用。

--ignore-submodules[=<when>]

在差异生成中忽略对子模块的更改。<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.noprefix、diff.srcPrefix、diff.dstPrefix和diff.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 生成补丁文本

运行git-diff[1]、git-log[1]、git-show[1]、git-diff-index[1]、git-diff-tree[1]或git-diff-files[1]并使用-p选项会生成补丁文本。您可以通过GIT_EXTERNAL_DIFF和GIT_DIFF_OPTS环境变量（参见git[1]）以及diff属性（参见gitattributes[5]）来自定义补丁文本的创建。

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

  1. 它前面带有如下所示的“git diff”头部。

    diff --git a/file1 b/file2

    除非涉及重命名/复制，否则a/和b/文件名相同。尤其是在创建或删除时，不会使用/dev/null代替a/或b/文件名。

    如果涉及重命名/复制，则file1和file2分别显示重命名/复制的源文件名和重命名/复制生成的文件名。

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

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

“合并 diff”格式如下所示。

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>行。带有关于检测到的内容移动（重命名和复制检测）信息的扩展头部旨在与两个<tree-ish>的 diff 一起使用，并且合并 diff 格式不使用它们。

  3. 其后跟着一个两行的 from-file/to-file 头部。

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

    类似于传统统一diff 格式的两行头部，/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。合并 diff 格式是为审查合并提交更改而创建的，并非旨在应用。此更改类似于扩展索引头部中的更改。

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

    合并 diff 格式的块头部中有（父级数 + 1）个@字符。

与显示两个文件 A 和 B 以及一个包含-（减号——出现在 A 中但在 B 中删除）、+（加号——在 A 中缺失但在 B 中添加）或" "（空格——未更改）前缀的单个列的传统统一diff 格式不同，此格式比较两个或多个文件 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 log --no-merges

显示整个提交历史记录，但跳过任何合并。

git log v2.6.12.. include/scsi drivers/scsi

显示自版本v2.6.12以来更改了include/scsi或drivers/scsi子目录中任何文件的任何提交。

git log --since="2 weeks ago" -- gitk

显示过去两周对文件gitk的更改。--是必要的，以避免与名为gitk的分支混淆。

git log --name-status release..test

显示“test”分支中但尚未在“release”分支中的提交，以及每个提交修改的路径列表。

git log --follow builtin/rev-list.c

显示更改了builtin/rev-list.c的提交，包括在该文件获得其当前名称之前发生的提交。

git log --branches --not --remotes=origin

显示任何本地分支中但不在origin的任何远程跟踪分支中的所有提交（您拥有的 origin 没有的）。

git log master --not --remotes=*/master

显示本地 master 中但不在任何远程存储库 master 分支中的所有提交。

git log -p -m --first-parent

显示包括更改差异的历史记录，但仅从“主分支”的角度，跳过来自合并分支的提交，并显示合并引入的更改的完整差异。这仅在遵循严格的策略（在保持单个集成分支的同时合并所有主题分支）时才有意义。

git log -L '/int main/',/^}/:main.c

显示文件main.c中函数main()如何随时间演变。

git log -3

将要显示的提交数量限制为 3 个。

讨论

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

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

  • 路径名以 UTF-8 规范化形式 C 编码。这适用于树对象、索引文件、引用名称，以及命令行参数、环境变量和配置文件（.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 和许多其他编码，但不包括 UTF-16/32、EBCDIC 和 CJK 多字节编码（GBK、Shift-JIS、Big5、EUC-x、CP9xx 等）。

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

  1. 如果给定的提交日志消息看起来不是有效的 UTF-8 字符串，git commit 和 git commit-tree 会发出警告，除非您明确说明您的项目使用的是传统编码。设置方法是在 .git/config 文件中添加 i18n.commitEncoding，如下所示

    [i18n]
	commitEncoding = ISO-8859-1

    使用上述设置创建的提交对象会在其 encoding 头部记录 i18n.commitEncoding 的值。这样可以帮助以后查看提交日志的人。如果没有这个头部，则表示提交日志消息使用 UTF-8 编码。

  2. git log、git show、git blame 及其他相关命令会查看提交对象的 encoding 头部，并尝试将日志消息重新编码为 UTF-8，除非另有指定。您可以使用 .git/config 文件中的 i18n.logOutputEncoding 指定所需的输出编码，如下所示

    [i18n]
	logOutputEncoding = ISO-8859-1

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

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

配置

有关核心变量，请参阅 git-config[1]；有关与差异生成相关的设置，请参阅 git-diff[1]。

format.pretty

--format 选项的默认值。（参见上面的漂亮格式。）默认为 medium。

i18n.logOutputEncoding

显示日志时使用的编码。（参见上面的讨论。）如果设置了 i18n.commitEncoding，则默认为其值；否则默认为 UTF-8。

本节中上面所有内容均未包含在 git-config[1] 文档中。以下内容与该文档中的内容相同

log.abbrevCommit

如果为真，则使 git-log[1]、git-show[1] 和 git-whatchanged[1] 假设 --abbrev-commit。您可以使用 --no-abbrev-commit 覆盖此选项。

log.date

设置 log 命令的默认日期时间模式。设置 log.date 的值类似于使用 git log 的 --date 选项。有关详细信息，请参阅 git-log[1]。

如果格式设置为“auto:foo”并且正在使用分页器，则将“foo”用作日期格式。否则，将使用“default”。

log.decorate

打印出 log 命令显示的任何提交的 ref 名称。如果指定了 short，则不会打印 ref 名称前缀 refs/heads/、refs/tags/ 和 refs/remotes/。如果指定了 full，则将打印完整的 ref 名称（包括前缀）。如果指定了 auto，则如果输出到终端，则 ref 名称将显示为 short 所指定的那样，否则不显示 ref 名称。这与 git log 的 --decorate 选项相同。

log.initialDecorationSet

默认情况下，git log 仅显示某些已知 ref 命名空间的修饰。如果指定了 all，则显示所有 ref 作为修饰。

log.excludeDecoration

从日志修饰中排除指定的模式。这类似于 --decorate-refs-exclude 命令行选项，但 config 选项可以被 --decorate-refs 选项覆盖。

log.diffMerges

设置在指定 --diff-merges=on 时使用的 diff 格式，有关详细信息，请参阅 git-log[1] 中的 --diff-merges。默认为 separate。

log.follow

如果为 true，则 git log 将在给出单个 <path> 时表现得好像使用了 --follow 选项一样。这具有与 --follow 相同的限制，即它不能用于跟踪多个文件，并且在非线性历史记录上效果不佳。

log.graphColors

一系列用逗号分隔的颜色，可用于在 git log --graph 中绘制历史记录线。

log.showRoot

如果为真，则初始提交将显示为一个大型创建事件。这相当于针对空树的差异。像 git-log[1] 或 git-whatchanged[1] 这样的工具通常会隐藏根提交，现在会显示它。默认情况下为真。

log.showSignature

如果为真，则使 git-log[1]、git-show[1] 和 git-whatchanged[1] 假设 --show-signature。

log.mailmap

如果为真，则使 git-log[1]、git-show[1] 和 git-whatchanged[1] 假设 --use-mailmap，否则假设 --no-use-mailmap。默认情况下为真。

notes.mergeStrategy

在解决注释冲突时默认选择哪个合并策略。必须是 manual、ours、theirs、union 或 cat_sort_uniq 之一。默认为 manual。有关每个策略的更多信息，请参阅 git-notes[1] 的“注释合并策略”部分。

此设置可以通过将 --strategy 选项传递给 git-notes[1] 来覆盖。

notes.<name>.mergeStrategy

在将注释合并到 refs/notes/<name> 时选择哪个合并策略。这将覆盖更通用的“notes.mergeStrategy”。有关可用策略的更多信息，请参阅 git-notes[1] 中的“注释合并策略”部分。

notes.displayRef

除了 core.notesRef 或 GIT_NOTES_REF 设置的默认值之外，还要读取哪个 ref（或 ref，如果为通配符或指定了多次），以便在使用 git log 系列命令显示提交消息时读取注释。

此设置可以使用 GIT_NOTES_DISPLAY_REF 环境变量覆盖，该变量必须是 ref 或通配符的冒号分隔列表。

将为不存在的 ref 发出警告，但与任何 ref 均不匹配的通配符将被静默忽略。

可以使用 git log 系列命令的 --no-notes 选项或这些命令接受的 --notes=<ref> 选项禁用此设置。

“core.notesRef”的有效值（可能被 GIT_NOTES_REF 覆盖）也会隐式添加到要显示的 ref 列表中。

notes.rewrite.<command>

当使用 <command>（当前为 amend 或 rebase）重写提交时，如果此变量为 false，则 git 不会将注释从原始提交复制到重写后的提交。默认为 true。另请参见下面的“notes.rewriteRef”。

此设置可以使用 GIT_NOTES_REWRITE_REF 环境变量覆盖，该变量必须是 ref 或通配符的冒号分隔列表。

notes.rewriteMode

在重写期间复制注释时（请参阅“notes.rewrite.<command>”选项），如果目标提交已经具有注释，则确定该怎么办。必须是 overwrite、concatenate、cat_sort_uniq 或 ignore 之一。默认为 concatenate。

此设置可以使用 GIT_NOTES_REWRITE_MODE 环境变量覆盖。

notes.rewriteRef

在重写期间复制注释时，指定应复制其注释的（完全限定的）ref。可以是通配符，在这种情况下，将复制所有匹配 ref 中的注释。您也可以多次指定此配置。

没有默认值；您必须配置此变量才能启用注释重写。将其设置为 refs/notes/commits 以启用对默认提交注释的重写。

可以使用 GIT_NOTES_REWRITE_REF 环境变量覆盖。有关其格式的进一步说明，请参阅上面的 notes.rewrite.<command>。

Git

是 git[1] 套件的一部分

scroll-to-top