简体中文 ▾ 主题 ▾ 最新版本 ▾ git-log 上次更新于 2.52.0

名称

git-log - 显示提交日志

概要

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

描述

显示提交日志。

通过跟随给定提交的 父提交 链接可到达的提交列表,但排除从带 ^ 前缀的提交可到达的提交。默认按时间倒序输出。

您可以将其视为集合运算。命令行上给出的任何提交所能到达的提交构成一个集合,然后从该集合中减去带 ^ 前缀的提交所能到达的提交。剩余的提交是命令的输出。可以使用各种其他选项和路径参数来进一步限制结果。

因此,以下命令

$ git log foo bar ^baz

表示“列出所有可从 foobar 到达,但不能从 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)]

打印出任何显示提交的引用名称。可能的值为

`short`;; the ref name prefixes `refs/heads/`, `refs/tags/` and
	`refs/remotes/` are not printed.
`full`;; the full ref name (including prefix) is printed.
`auto`:: if the output is going to a terminal, the ref names
	are shown as if `short` were given, otherwise no ref names are
	shown.

选项 --decorate--decorate=short 的简写。如果已配置,则默认为 log.decorate 的配置值,否则为 auto

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

对于每个候选引用,如果它与 --decorate-refs-exclude 给出的任何 <pattern> 参数匹配,或者如果它不与 --decorate-refs 给出的任何 <pattern> 参数匹配,则不使用它进行装饰。 log.excludeDecoration 配置选项允许排除用于装饰的引用,但显式的 --decorate-refs 模式将覆盖 log.excludeDecoration 中的匹配项。

如果未给出这些选项或配置设置,则当引用匹配 HEADrefs/heads/refs/remotes/refs/stash/refs/tags/ 时,将使用这些引用作为装饰。

--clear-decorations

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

--source

打印出通过该命令给出的引用名称,每个提交都是通过该引用名称到达的。

--mailmap
--no-mailmap
--use-mailmap
--no-use-mailmap

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

--full-diff

如果不使用此标志,git log -p <path>... 会显示接触指定路径的提交,并显示有关相同指定路径的 diff。使用此选项时,将显示接触指定路径的提交的完整 diff;这意味着 "<path>..." 仅限制提交,而不限制这些提交的 diff。

请注意,这会影响所有基于 diff 的输出类型,例如由 --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 抑制补丁输出,但其他 diff 格式(即 --raw--numstat--shortstat--dirstat--summary--name-only--name-status--check)目前未实现。

<start><end> 可以采用以下形式之一

  • <number>

    如果 <start><end> 是一个数字,它指定一个绝对行号(行从 1 开始计数)。

  • /<regex>/

    此形式将使用第一个匹配给定 POSIX <regex> 的行。如果 <start> 是一个正则表达式,它将从上一个 -L 范围的末尾(如果存在)开始搜索,否则从文件开头开始搜索。如果 <start>^/<regex>/,它将从文件开头开始搜索。如果 <end> 是一个正则表达式,它将从 <start> 给定的行开始搜索。

  • +<offset>-<offset>

    这仅对 <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>

将输出限制为 <number> 个提交。

--skip=<number>

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

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

显示比 <date> 更新的提交。

--since-as-filter=<date>

显示所有比 <date> 更新的提交。这会遍历范围内的所有提交,而不是在第一个比 <date> 旧的提交处停止。

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

显示比 <date> 旧的提交。

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

将提交输出限制为作者/提交者标题行与 <pattern> 正则表达式匹配的提交。使用多个 --author=<pattern> 时,会选择作者匹配任何 <pattern> 的提交(对多个 --committer=<pattern> 类似)。

--grep-reflog=<pattern>

将提交输出限制为 reflog 条目与 <pattern> 正则表达式匹配的提交。使用多个 --grep-reflog 时,会选择 reflog 消息匹配任何给定模式的提交。使用此选项但未同时使用 --walk-reflogs 是错误的。

--grep=<pattern>

将提交输出限制为其日志消息匹配 <pattern> 正则表达式的提交。使用多个 --grep=<pattern> 时,会选择消息匹配任何 <pattern> 的提交(但请参阅 --all-match)。

--notes 生效时,来自备注的消息将像日志消息的一部分一样进行匹配。

--all-match

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

--invert-grep

将提交输出限制为其日志消息不匹配使用 --grep=<pattern> 指定的 <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/ 中的所有引用以及 HEAD 都已在命令行上列为 <commit>

--branches[=<pattern>]

假装 refs/heads 中的所有引用都已在命令行上列为 <commit>。如果给出了 <pattern>,则将分支限制为与给定 shell glob 匹配的分支。如果 <pattern> 缺少 ?*[,则在末尾隐含 /*

--tags[=<pattern>]

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

--remotes[=<pattern>]

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

--glob=<glob-pattern>

假装所有匹配 shell glob <glob-pattern> 的引用都已在命令行上列为 <commit>。如果缺少,则自动加上前缀 refs/。如果模式缺少 ?*[,则在末尾隐含 /*

--exclude=<glob-pattern>

不包括与下一个 --all--branches--tags--remotes--glob 将要考虑的 <glob-pattern> 匹配的引用。此选项的重复使用会累积排除模式,直到下一个 --all--branches--tags--remotes--glob 选项(其他选项或参数不会清除累积的模式)。

当应用于 --branches--tags--remotes 时,给出的模式不应分别以 refs/headsrefs/tagsrefs/remotes 开头,并且当应用于 --glob--all 时,它们必须以 refs/ 开头。如果要匹配结尾的 /*,则必须显式给出。

--exclude-hidden=(fetch|receive|uploadpack)

通过查阅适当的 fetch.hideRefsreceive.hideRefsuploadpack.hideRefs 配置以及 transfer.hideRefs(请参阅 git-config[1]),不包括会被 git-fetchgit-receive-packgit-upload-pack 隐藏的引用。此选项会影响下一个伪引用选项 --all--glob,并在处理它们之后清除。

--reflog

假装由 reflog 提及的所有对象都已在命令行上列为 <commit>

--alternate-refs

假装备用存储库的引用尖端中提到的所有对象都已在命令行上列出。备用存储库是其对象目录在 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=。当看到 -- 分隔符时,后面的输入被视为路径并用于限制结果。通过 stdin 读取的标志(如 --not)仅对以相同方式传递的参数有效,并且不会影响任何后续命令行参数。

--cherry-mark

类似于 --cherry-pick(见下文),但用 = 标记等效提交而不是省略它们,用 + 标记不等效提交。

--cherry-pick

当提交集合通过对称差异限制时,省略与“另一侧”的另一个提交引入相同更改的任何提交。

例如,如果您有两个分支 AB,列出它们其中一个分支上所有提交的常用方法是使用 --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 中的提交补丁等效的提交从 B 中省略。换句话说,这列出了 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> 表示法)。

使用 --pretty 格式(onelinereference 除外,原因显而易见),这会导致输出包含来自 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_HEADCHERRY_PICK_HEADREVERT_HEADREBASE_HEAD 中的第一个存在的伪引用。仅当索引包含未合并条目时才有效。此选项可用于在解决 3 路合并冲突时显示相关提交。

--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> 的后代,或者 <commit> 本身的提交。如果没有指定提交,则将 <commit1>(范围中排除的部分)用作 <commit>。可以多次传递;如果是这样,如果一个提交是给定的任何提交之一,或者它是其中一个的祖先或后代,则包含该提交。

更详细的解释如下。

假设您指定了 foo 作为 <paths>。我们将调用修改 foo 的提交为 !TREESAME,其余的为 TREESAME。(在为 foo 过滤的 diff 中,它们分别看起来不同和相同。)

在下文中,我们将始终引用相同的历史示例来阐述简化设置之间的差异。我们假设您正在此提交图中过滤文件 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)。

  • Dfoo 设置为 baz。其合并 OND 的字符串合并为 foobarbaz;即,它与任何父项都不同(!TREESAME)。

  • Equux 更改为 xyzzy,其合并 P 将字符串合并为 quux xyzzyPO 是 TREESAME,但与 E 不是。

  • X 是一个独立的根提交,它添加了一个新文件 side,而 Y 修改了它。YX 是 TREESAME。其合并 Qside 添加到 P,而 QP 是 TREESAME,但与 Y 不是。

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

默认模式

包含的提交是那些与任何父项都不同的提交(尽管这可以改变,请参见下文的 --sparse)。如果提交是合并,并且它与一个父项是 TREESAME,则只跟随该父项。(即使有多个 TREESAME 父项,也只跟随其中一个。)否则,跟随所有父项。

这导致

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

请注意,如果存在 TREESAME 父项,则只跟随该 TREESAME 父项的规则如何使 B 完全被排除。 C 是通过 N 考虑的,但它是 TREESAME。根提交与空树进行比较,因此 I 是 !TREESAME。

父/子关系仅在 --parents 选项下可见,但这不影响默认模式下选择的提交,因此我们已显示父行。

--full-history,不进行父项重写

此模式与默认模式仅有一处不同:总是跟随合并的所有父项,即使它与其中一个父项是 TREESAME。即使合并的多个分支都包含提交,这也不意味着合并本身会被包含!在示例中,我们得到:

	I  A  B  N  D  O  P  Q

M 被排除是因为它与两个父项都是 TREESAME。 ECB 都被遍历,但只有 B 是 !TREESAME,因此其他的不出现。

请注意,如果没有父级重写,很难真正谈论提交之间的父/子关系,因此我们将它们显示为断开连接。

--full-history,进行父项重写

普通提交仅在它们是 !TREESAME 时才包含(尽管这可以更改,请参阅下面的 --sparse)。

合并总是被包含。然而,它们的父列表被重写:沿每个父列表,修剪掉本身未包含的提交。这导致

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

与上面的“不进行父项重写的 --full-history”进行比较。请注意,E 被删除了,因为它本身是 TREESAME,但 P 的父项列表被重写为包含 E 的父项 I。对于 CN,以及 XYQ,也发生了同样的情况。

除了上述设置之外,您还可以更改 TREESAME 是否影响包含

--dense

被遍历的提交如果与任何父级都不是 TREESAME,则会被包含。

--sparse

所有被遍历的提交都将被包含。

请注意,没有 --full-history,这仍然会简化合并:如果其中一个父级是 TREESAME,我们只跟踪那一个,因此合并的其他侧永远不会被遍历。

--simplify-merges

首先,以与 --full-history 带父级重写相同的方式构建历史图(见上文)。

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

  • C' 设置为 C

  • C' 的每个父项 P 替换为其简化后的 P'。在此过程中,删除是其他父项的祖先或与空树 TREESAME 的根提交的父项,并删除重复项,但注意永远不要删除所有我们是 TREESAME 的父项。

  • 如果在此父重写之后,C' 是一个根提交或合并提交(具有零或 >1 个父级),一个边界提交,或 !TREESAME,则它保持不变。否则,它将被其唯一父级替换。

通过与带父重写的 --full-history 进行比较,最能体现其效果。示例变为

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

注意 NPQ 相对于 --full-history 的主要区别:

  • N 的父项列表中删除了 I,因为它是另一个父项 M 的祖先。但是,N 仍然被保留,因为它与任何父项都不同(!TREESAME)。

  • P 的父列表类似地移除了 IP 随后被完全移除,因为它有一个父级且是 TREESAME。

  • Q 的父项列表将 Y 简化为 XX 然后被删除,因为它是一个 TREESAME 的根提交。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 引入的 bug 的污染并需要修复时,我们可能只想查看 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
		 \
	      C---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` 的内容并仅采用 X 处 `file.txt` 的内容而创建的。因此,R 与 X 是 TREESAME,但与 M 不是。最后,创建 N 的自然合并解析是采用 R 处 `file.txt` 的内容,因此 N 与 R 是 TREESAME,但与 C 不是。合并提交 O 和 P 与它们的第一个父项是 TREESAME,但与它们的第二个父项 Z 和 Y 分别不是。

在使用默认模式时,NR 都具有一个 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 的重写后的第二个父项可以从它们的第一个父项到达。这些边被移除,然后这些提交看起来像单父提交,并且与它们的父项是 TREESAME。提交 N 也发生这种情况,导致历史视图如下:

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

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

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

第二个问题是审计。当许多贡献者在同一个存储库中工作时,哪个合并提交将更改引入重要分支是很重要的。上面的有问题的合并 R 很可能不是用于将 R 合并到重要分支的合并提交。相反,合并 N 用于将 R 和 X 合并到重要分支。该提交可能包含有关 X 的更改覆盖 A 和 B 的更改原因的信息。

--show-pulls

除了默认历史中显示的提交外,显示每个与其第一个父级不是 TREESAME 但与其后续父级是 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---

其中数字表示提交时间戳的顺序,git rev-list 和其他带有 --date-order 的命令会按时间戳顺序显示提交: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>` 选项(它也会修改 diff 输出,如果显示的话)来指定前缀的最小长度。

这应该能让使用 80 列终端的人更容易阅读 `--pretty=oneline`。

--no-abbrev-commit

显示完整的 40 字节十六进制提交对象名。这会否定 `--abbrev-commit`(无论是显式的还是其他选项如 `--oneline` 暗示的)。它还会覆盖 `log.abbrevCommit` 变量。

--oneline

这是 `--pretty=oneline --abbrev-commit` 的简写。

--encoding=<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])注解的提交。这是 `git log`、`git show` 和 `git whatchanged` 命令的默认行为,当命令行上没有给出 `--pretty`、`--format` 或 `--oneline` 选项时。

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

使用可选的 <ref> 参数,使用该 ref 来查找要显示的注释。当 ref 以 `refs/notes/` 开头时,它可以指定完整的 refname;当它以 `notes/` 开头时,`refs/` 和其他情况会加上 `refs/notes/` 前缀来形成 ref 的完整名称。

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

--no-notes

不显示注释。这会否定上面的 `--notes` 选项,通过重置从中显示注释的 notes ref 列表。选项是按命令行给出的顺序解析的,因此例如“`--notes --notes=foo --no-notes --notes=bar`”将只显示来自 `refs/notes/bar` 的注释。

--show-notes-by-default

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

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

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

--show-signature

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

--relative-date

等同于 --date=relative

--date=<format>

仅在以人类可读格式显示日期时生效(例如,使用 `--pretty` 时)。`log.date` 配置变量为 `git 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:<format>` 将 <format> 传递给系统的 `strftime`,但 `%s`、`%z` 和 `%Z` 除外,它们由内部处理。使用 `--date=format:%c` 以系统区域设置的首选格式显示日期。有关格式占位符的完整列表,请参阅 `strftime`(3) 手册。使用 `-local` 时,正确的语法是 `--date=format-local:<format>`。

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

如果该提交是合并提交,并且美化格式不是 `oneline`、`email` 或 `raw`,则在 `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 选项,否则日期格式为 --date=short。与任何带有格式占位符的 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* 信息显示真实的父提交,而不考虑 graft 或历史简化。请注意,此格式会影响提交的显示方式,但不会影响 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<spec>)

      颜色规范,如 git-config[1]“配置文件”部分中的“值”中所述。默认情况下,仅当为日志输出启用了颜色时(通过 color.diff、color.ui 或 --color,并且如果输出到终端,则尊重前者的 auto 设置)才会显示颜色。%(auto,<spec>) 被接受为默认值的历史同义词(例如,%(auto,red))。指定 %(always,<spec>) 将显示颜色,即使颜色未被启用(但可以考虑仅使用 --color=always 来为整个输出启用颜色,包括此格式和 Git 可能着色的任何其他内容)。单独的 auto(即 %(auto))将在下一个占位符之前自动打开颜色,直到颜色再次切换。

      %m

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

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

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

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

      使下一个占位符至少占用 N 列宽度,如果需要,则在右侧填充空格。如果输出超过 N 列,则可以选择在左侧(ltrunc)截断(使用省略号 ..),在中间(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[:<option>,...]

      带有自定义装饰的 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[:<option>,...]

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

    • tags[=<bool-value>]:而不是只考虑带注释的标签,也考虑轻量级标签。

    • abbrev=<number>:而不是使用默认的十六进制数字数量(这将根据存储库中的对象数量而变化,默认为 7),使用 <number> 位数字,或者根据需要使用的数字以形成唯一的对象名称。

    • match=<pattern>:只考虑匹配给定 glob(7) <pattern> 的标签,不包括 refs/tags/ 前缀。

    • exclude=<pattern>:不考虑匹配给定 glob(7) <pattern> 的标签,不包括 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

    引用日志身份名称

    %gN

    引用日志身份名称(遵循 .mailmap,参见 git-shortlog[1]git-blame[1]

    %ge

    引用日志身份电子邮件

    %gE

    引用日志身份电子邮件(遵循 .mailmap,参见 git-shortlog[1]git-blame[1]

    %gs

    引用日志主题

    %(trailers[:<option>,...]

    显示由 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)。如果命令行为未提供 --decorate,则 %d 和 %D 占位符将使用 "short" 装饰格式。

布尔选项接受一个可选值 [=<bool-value>]。--type=bool git-config[1] 中的值,如 yes 和 off,都被接受。给出布尔选项而不带 =<value> 等同于给出 =true。

如果在占位符的 % 后面加上 +(加号),当且仅当占位符扩展为非空字符串时,会在其扩展之前立即插入一个换行符。

如果在占位符的 % 后面加上 -(减号),当且仅当占位符扩展为空字符串时,会删除扩展之前所有连续的换行符。

如果在占位符的 % 后面加上空格,当且仅当占位符扩展为非空字符串时,会在其扩展之前立即插入一个空格。

  • 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

DIFF FORMATTING

默认情况下,git log 不生成任何 diff 输出。下面的选项可用于显示每个提交所做的更改。

请注意,除非显式给出了 --diff-merges 变体(包括 short -m、-c、--cc 和 --dd 选项之一),否则合并提交将不会显示 diff,即使选择了 --patch 等 diff 格式,它们也不会匹配 -S 等搜索选项。例外情况是当使用 --first-parent 时,在这种情况下,对于合并提交,first-parent 是默认格式。

-p
-u
--patch

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

-s
--no-patch

禁止 diff 引擎的所有输出。这对于像 git show 这样默认显示 patch 的命令很有用,可以抑制其输出,或者取消命令行中别名(alias)中像 --patch--stat 等选项的影响。

-m

以默认格式显示合并提交的 diff。这类似于 --diff-merges=on,但 -m 除非同时给出了 -p,否则不会产生任何输出。

-c

为合并提交生成组合 diff 输出。--diff-merges=combined -p 的快捷方式。

--cc

为合并提交生成密集组合 diff 输出。--diff-merges=dense-combined -p 的快捷方式。

--dd

相对于第一个父提交显示合并提交和常规提交的 diff。--diff-merges=first-parent -p 的快捷方式。

--remerge-diff

为合并提交生成 remerge-diff 输出。--diff-merges=remerge -p 的快捷方式。

--no-diff-merges

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

--diff-merges=<format>

指定用于合并提交的 diff 格式。默认是 `off`,除非使用了 `--first-parent`,在这种情况下,`first-parent` 是默认值。

支持以下格式

off
none

禁用合并提交的 diff 输出。用于覆盖隐含值。

on
m

使合并提交的 diff 输出以默认格式显示。默认格式可以通过 log.diffMerges 配置变量更改,该变量的默认值为 separate。

first-parent
1

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

separate

显示相对于每个父提交的完整 diff。为每个父提交生成单独的日志条目和 diff。

combined
c

同时显示每个父提交与合并结果之间的差异,而不是一次显示一个父提交与结果之间的成对 diff。此外,它只列出了与所有父提交相比被修改过的文件。

dense-combined
cc

通过省略其在父提交中的内容只有两种变体且合并结果未修改地选取其中一种的非相关 hunks,进一步压缩 --diff-merges=combined 产生的输出。

remerge
r

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

使用此选项时发出的输出可能会更改,其与其他选项的交互也是如此(除非有明确记录)。

--combined-all-paths

使组合 diff(用于合并提交)列出所有父提交的文件名。因此,它仅在使用了 --diff-merges=[dense-]combined 时才有效,并且只有在检测到文件名更改时(即,当请求了重命名或复制检测时)才可能有用。

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

生成包含 <n> 行上下文(而不是通常的三行)的 diff。隐含 --patch

--output=<file>

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

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

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

--raw

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

--patch-with-raw

-p --raw 的同义词。

-t

在 diff 输出中显示树对象。

--indent-heuristic

启用启发式算法,该算法会移动差异块边界,使补丁更易于阅读。这是默认设置。

--no-indent-heuristic

禁用缩进启发式算法。

--minimal

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

--patience

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

--histogram

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

--anchored=<text>

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

此选项可以多次指定。

如果一行在源和目标中都存在,只存在一次,并且以 <text> 开头,则此算法会尝试阻止其在输出中显示为删除或添加。它内部使用“patience diff”算法。

--diff-algorithm=(patience|minimal|histogram|myers)

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

default
myers

基本的贪婪差异算法。目前,这是默认值。

minimal

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

patience

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

histogram

此算法扩展了 patience 算法以“支持低出现率的常见元素”。

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

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

生成 diffstat。默认情况下,文件名部分会使用尽可能多的空间,其余部分用于图表部分。最大宽度默认为终端宽度,如果未连接到终端则为 80 列,并且可以通过 <width> 覆盖。文件名部分的宽度可以通过提供一个逗号分隔的宽度 <name-width> 来限制,或者通过设置 diff.statNameWidth=<name-width> 来设置。图表部分的宽度可以通过使用 --stat-graph-width=<graph-width> 或设置 diff.statGraphWidth=<graph-width> 来限制。使用 --stat--stat-graph-width 会影响所有生成 stat 图的命令,而设置 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 [<param>,...]
--dirstat[=<param>,...]

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

changes

通过计算源文件中删除的行数或目标文件中添加的行数来计算 dirstat 数字。这会忽略纯代码移动 within a file 的量。换句话说,重新排列文件中的行不如其他更改计数多。这是未提供任何参数时的默认行为。

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[=<param>,...]

--dirstat=files,<param>,... 的同义词。

--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 时,使用 short 格式。此格式仅显示范围开始和结束时的提交名称。当指定 --submodule--submodule=log 时,使用 log 格式。此格式像 git-submodule[1] summary 一样列出范围内的提交。当指定 --submodule=diff 时,使用 diff 格式。此格式显示提交范围之间子模块内容更改的内联 diff。默认为 diff.submodule 或在配置选项未设置时为 short 格式。

--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 颜色显示。此模式可以识别所有移动的行,但在审查时,很难确定代码块是否在不改变顺序的情况下被移动。

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=<mode>,...

这配置了在执行 --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>]

默认情况下,单词由空白分隔;参见下面的 --word-diff-regex<mode> 默认为 plain,并且必须是以下之一:

color

仅使用颜色高亮显示更改的单词。隐含 --color

plain

将单词显示为 [-removed-]{added}。不尝试转义分隔符,如果它们出现在输入中,输出可能会有歧义。

porcelain

使用一种特殊的基于行的格式,用于脚本消耗。添加/删除/未更改的运行以通常的统一 diff 格式打印,行首有一个 +/-/` ` 字符,并延伸到行尾。输入中的换行符用单独一行上的波浪号 ~ 表示。

none

再次禁用单词 diff。

请注意,尽管第一个模式的名称如此,如果启用,所有模式都使用颜色高亮显示更改的部分。

--word-diff-regex=<regex>

使用 <regex> 来决定什么是单词,而不是将非空白字符的连续序列视为一个单词。除非已启用,否则这也隐含 --word-diff

<regex> 的每个非重叠匹配都被视为一个单词。这些匹配之间的任何内容都被视为空格并被忽略(!) 以用于查找差异。你可能希望在正则表达式后追加 |[^[:space:]] 以确保它匹配所有非空格字符。包含换行符的匹配会被静默截断(!) 在换行符处。

例如,--word-diff-regex=. 会将每个字符视为一个单词,并相应地逐字符显示差异。

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

--color-words[=<regex>]

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

--no-renames

关闭重命名检测,即使配置文件默认开启。

--rename-empty
--no-rename-empty

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

--check

当引入冲突标记或空格错误时发出警告。空格错误被认为是受 core.whitespace 配置控制的。默认情况下,行尾的空格(包括仅由空格组成的行)以及行开头缩进中紧跟在制表符后面的空格字符被视为空格错误。如果发现问题,退出状态将非零。与 --exit-code 不兼容。

--ws-error-highlight=<kind>

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

--full-index

在生成补丁格式输出时,不在“index”行上显示前几个字符,而是显示完整的原图像和后图像 blob 对象名称。

--binary

除了 --full-index 之外,还输出一个二进制 diff,该 diff 可以用 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>]]

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

它影响了将文件完全重写(rewrite)的更改的处理方式,而不是将其视为一系列删除和插入,其中只有少量文本碰巧与上下文匹配。它将其视为一次性的全部删除后一次性的全部插入,并且数字<m>控制 -B 选项的这一方面(默认为 60%)。-B/70% 指定,如果结果中保留的原始部分少于 30%,Git 将认为这是一次完全重写(即,否则生成的 patch 将是一系列删除和插入,并带有上下文行)。

当与 -M 一起使用时,完全重写的文件也被视为重命名(rename)的源头(通常 -M 只将消失的文件视为重命名的源头),数字 <n> 控制 -B 选项的这一方面(默认为 50%)。-B20% 指定与文件大小相比,增加和删除变化达到 20% 或以上的更改有资格被选作重命名到另一个文件的可能源头。

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

如果生成 diff,则为每个提交检测并报告重命名。要跟踪历史记录中文件重命名,请参阅 --follow。如果指定了 <n>,则它是相似性索引的阈值(即与文件大小相比的添加/删除量)。例如,-M90% 表示 Git 应将删除/添加对视为重命名,如果文件有 90% 以上未更改。如果不带 % 符号,则数字被视为带有小数点前的分数的。即 -M5 变为 0.5,因此等同于 -M50%。类似地,-M05 等同于 -M5%。要将检测限制为精确重命名,请使用 -M100%。默认相似性索引为 50%。

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

检测复制和重命名。另请参见 --find-copies-harder。如果指定了 <n>,其含义与 -M<n> 相同。

--find-copies-harder

为了性能原因,默认情况下 -C 选项仅在复制的原始文件在同一更改集(changeset)中被修改时才查找复制。此标志使命令检查未修改的文件作为复制源的候选。对于大型项目,这是一项非常耗时的操作,因此请谨慎使用。给出多个 -C 选项具有相同的效果。

-D
--irreversible-delete

省略删除的原始文件(preimage),即只打印标头,而不打印原始文件与 /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 会排除已添加和已删除的路径。

请注意,并非所有 diff 都能包含所有类型。例如,如果禁用对这些类型的检测,则不会出现已复制和已重命名条目。

-S<string>

查找更改文件中指定 <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> 之前的(即 *skip to*)文件,或将它们移至输出末尾(即 *rotate to*)。这些选项主要用于 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=<number>

在差异块之间显示上下文,最多达指定行数 <number>,从而合并彼此接近的块。默认为 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] 或 diff 管道命令启用。

--ignore-submodules[=(none|untracked|dirty|all)]

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

--src-prefix=<prefix>

显示给定的源前缀 <prefix> 而不是 "a/"。

--dst-prefix=<prefix>

显示给定的目标前缀 <prefix> 而不是 "b/"。

--no-prefix

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

--default-prefix

使用默认的源和目标前缀("a/" 和 "b/")。这将覆盖配置变量,如 diff.noprefixdiff.srcPrefixdiff.dstPrefixdiff.mnemonicPrefix(参见 git-config[1])。

--line-prefix=<prefix>

在每行输出前面添加一个额外的 <prefix>

--ita-invisible-in-index

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

--max-depth=<depth>

对于命令行上给出的每个路径说明符,最多向下递归 <depth> 层目录。值为 -1 表示无限制。不能与路径说明符中的通配符组合使用。给定一个包含 foo/bar/baz 的树,以下列表显示了每个选项集生成的匹配项

  • --max-depth=0 -- foo: foo

  • --max-depth=1 -- foo: foo/bar

  • --max-depth=1 -- foo/bar: foo/bar/baz

  • --max-depth=1 -- foo foo/bar: foo/bar/baz

  • --max-depth=2 -- foo: foo/bar/baz

如果没有给出路径说明符,则深度测量方式就好像所有顶级条目都被指定一样。请注意,这与从根开始测量不同,因为 --max-depth=0 仍将返回 foo。这允许您在要求顶级条目子集的同时仍然限制深度。

请注意,此选项仅支持树对象之间的差异,不支持与索引或工作树的差异。

有关这些通用选项的更详细说明,另请参见 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_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>

    文件模式 <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. Hunk 头会提及 hunk 应用到的函数名称。有关如何根据特定语言进行调整的详细信息,请参见 gitattributes[5] 中的“定义自定义 hunk-header”。

组合 diff 格式

任何生成 diff 的命令都可以接受 -c--cc 选项,以便在显示合并时生成 *combined 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 设计的,并且不用于 combined diff 格式。

  3. 后面跟着一个两行的“源文件/目标文件”头:

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

    类似于传统 unified diff 格式的两行头,/dev/null 用于指示已创建或已删除的文件。

    然而,如果提供了 --combined-all-paths 选项,您将得到一个 N+1 行的“源文件/目标文件”头,而不是两行的“源文件/目标文件”头,其中 N 是合并提交中父级的数量:

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

    如果重命名或复制检测处于活动状态,这种扩展格式会很有用,可以让您查看不同父级中文件的原始名称。

  4. 块头格式已修改,以防止人们意外地将其馈送给 patch -p1。Combined diff 格式是为审查合并提交更改而创建的,不用于应用。更改类似于扩展的 index 标头中的更改。

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

    组合 diff 格式的块头中有(父级数量 + 1)个 @ 字符。

与传统的 *unified* diff 格式(显示两个文件 A 和 B,并带有一个单列,该列有 -(减号 — 出现在 A 中但从 B 中移除)、+(加号 — 在 A 中缺失但添加到 B 中),或 " "(空格 — 未更改)前缀)不同,此格式比较两个或多个文件 file1、file2、…… 和一个文件 X,并显示 X 与 fileN 的不同之处。文件 fileN 的数量加上每行输出中的一个列,用于指示 X 的行与该文件有何不同。

列 N 中的 - 字符表示该行出现在 fileN 中,但不在结果中。列 N 中的 + 字符表示该行出现在结果中,但 fileN 没有该行(换句话说,从该父级的角度来看,该行已被添加)。

在上面的示例输出中,函数签名与两个文件都不同(因此从 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/scsidrivers/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

显示包含更改 diff 的历史记录,但仅从“主分支”的角度来看,跳过来自合并分支的提交,并显示合并引入的更改的完整 diff。这仅在遵循严格的策略,即在单个集成分支上合并所有主题分支时才有意义。

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

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

git log -3

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

讨论

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

  • blob 对象的内容是未经解释的字节序列。核心层面没有编码转换。

  • 路径名以 UTF-8 规范形式 C 进行编码。这适用于 tree 对象、索引文件、引用名称,以及命令行参数、环境变量和配置文件(.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 Porcelain 都被设计为不强制项目使用 UTF-8。如果某个项目的参与者发现使用遗留编码更方便,Git 并不禁止。但是,有几点需要注意。

  1. git commitgit commit-tree 会在提交日志消息看起来不像有效的 UTF-8 字符串时发出警告,除非你明确声明你的项目使用遗留编码。通过在 .git/config 文件中设置 i18n.commitEncoding 来声明,例如:

    [i18n]
    	commitEncoding = ISO-8859-1

    使用上述设置创建的提交对象会将其 i18n.commitEncoding 的值记录在它们的 encoding 头中。这是为了帮助以后查看它们的人。缺少此头表示提交日志消息是 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-config[1];有关与 diff 生成相关的设置,请参阅 git-diff[1]

format.pretty

--format 选项的默认值。(参见上面的Pretty Formats。)默认为 medium

i18n.logOutputEncoding

显示日志时要使用的编码。(参见上面的Discussion。)如果设置了 i18n.commitEncoding,则默认为其值,否则默认为 UTF-8。

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

log.abbrevCommit

如果为 true,则使 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

打印日志命令显示的任何提交的 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 命令行选项,但配置选项可以被 --decorate-refs 选项覆盖。

log.diffMerges

设置指定 --diff-merges=on 时要使用的 diff 格式,有关详细信息,请参阅 git-log 中的 --diff-mergesseparate 是默认值。

log.follow

如果为 true,则当只给定一个 <path> 时,git log 的行为将如同使用了 --follow 选项。这与 --follow 具有相同的限制,即不能用于跟踪多个文件,并且在非线性历史记录上效果不佳。

log.graphColors

git log --graph 中用于绘制历史记录线的颜色列表,用逗号分隔。

log.showRoot

如果为 true,则初始提交将显示为一个大的创建事件。这等同于与空树的 diff。像 git-log[1]git-whatchanged[1] 这样的工具,通常会隐藏根提交,但现在会显示它。默认为 true。

log.showSignature

如果为 true,则使 git-log[1]git-show[1]git-whatchanged[1] 假定为 --show-signature

log.mailmap

如果为 true,则使 git-log[1]git-show[1]git-whatchanged[1] 假定为 --use-mailmap,否则假定为 --no-use-mailmap。默认为 true。

notes.mergeStrategy

解决 notes 冲突时默认选择的合并策略。必须是 manualourstheirsunioncat_sort_uniq 之一。默认为 manual。有关每种策略的更多信息,请参阅 git-notes[1] 的“NOTES MERGE STRATEGIES”部分。

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

notes.<name>.mergeStrategy

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

notes.displayRef

除了由 core.notesRefGIT_NOTES_REF 默认设置之外,还从哪个 ref(或 refs,如果是 glob 或指定多次)读取 notes,用于在显示提交消息时(使用 git-log[1] 系列命令)。

此设置可以通过 GIT_NOTES_DISPLAY_REF 环境变量覆盖,该变量必须是一个以冒号分隔的引用或 glob 列表。

对于不存在的引用将发出警告,但与任何引用不匹配的 glob 将被静默忽略。

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

core.notesRef 的有效值(可能被 GIT_NOTES_REF 覆盖)也会隐式添加到要显示的引用列表中。

notes.rewrite.<command>

使用 <command>(当前为 amendrebase)重写提交时,如果此变量为 false,则 git 不会从原始提交复制 notes 到重写的提交。默认为 true。另请参阅下面的 notes.rewriteRef

此设置可以通过 GIT_NOTES_REWRITE_REF 环境变量覆盖,该变量必须是一个以冒号分隔的引用或 glob 列表。

notes.rewriteMode

复制重写笔记时(请参阅 notes.rewrite.<command> 选项),确定在目标提交已包含笔记时应执行的操作。必须是以下值之一:overwriteconcatenatecat_sort_uniqignore。默认为 concatenate

此设置可以通过 GIT_NOTES_REWRITE_MODE 环境变量覆盖。

notes.rewriteRef

在重写期间复制备注时,指定(完全限定的)要复制备注的引用。可以是一个 glob,在这种情况下,所有匹配引用中的备注都将被复制。您也可以多次指定此配置。

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

可以通过 GIT_NOTES_REWRITE_REF 环境变量覆盖。有关其格式的进一步描述,请参见上面的 notes.rewrite.<command>

GIT

Git[1] 套件的一部分