简体中文 ▾ 主题 ▾ 最新版本 ▾ git-rev-list 最后更新于 2.50.0

名称

git-rev-list - 按逆时间顺序列出提交对象

概要

git rev-list [<options>] <commit>…​ [--] [<path>…​]

描述

列出从给定提交（或多个提交）通过跟踪 parent 链接可达的提交，但排除那些在前面带有 *^* 符号的提交所能到达的提交。默认情况下，输出按逆时间顺序排列。

你可以将其视为一种集合操作。从命令行给定的任何提交可达到的提交构成一个集合，然后从那些前面带有 *^* 符号的提交可达到的提交将从该集合中减去。剩余的提交就是该命令的输出。可以使用各种其他选项和路径参数来进一步限制结果。

因此，以下命令

$ git rev-list foo bar ^baz

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

特殊表示法“<commit1>..<commit2>”可用作“^<commit1> <commit2>”的简写。例如，以下任一用法均可互换：

$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin

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

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

rev-list 是一个重要的 Git 命令，因为它提供了构建和遍历提交祖先图的能力。因此，它有许多不同的选项，使其可以被 `git bisect` 和 `git repack` 等不同命令使用。

选项

提交限制

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

使用更多选项通常会进一步限制输出（例如，--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>

显示特定日期之前的所有提交。

--max-age=<timestamp>
--min-age=<timestamp>

将提交输出限制在指定的时间范围内。

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

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

--grep-reflog=<pattern>

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

--grep=<pattern>

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

--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 表示所有章鱼合并（octopus merges）。

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

--first-parent

在查找要包含的提交时，遇到合并提交时只跟踪第一个父提交。在查看特定主题分支的演变时，此选项可以提供更好的概览，因为合并到主题分支通常只是为了不时地调整上游更新，此选项允许您忽略此类合并带入历史记录的单个提交。

--exclude-first-parent-only

在查找要排除的提交时（带有 *^* ），遇到合并提交时只跟踪第一个父提交。这可以用于查找主题分支中从其与远程分支分歧点开始的变更集，因为任意合并都可以是有效的主题分支变更。

--not

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

--all

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

--branches[=<pattern>]

假装 refs/heads 中的所有引用都以 <commit> 的形式在命令行中列出。如果提供了 <pattern>，则将分支限制为匹配给定 shell glob 模式的分支。如果模式缺少 ?、* 或 [，则隐含结尾的 /*。

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

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

当分别应用于 --branches、--tags 或 --remotes 时，给定的模式不应以 refs/heads、refs/tags 或 refs/remotes 开头；当应用于 --glob 或 --all 时，它们必须以 refs/ 开头。如果意图包含尾部的 /*，则必须明确给出。

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

通过查阅相应的 fetch.hideRefs、receive.hideRefs 或 uploadpack.hideRefs 配置以及 transfer.hideRefs（参见 git-config[1]），不包括会被 git-fetch、git-receive-pack 或 git-upload-pack 隐藏的引用。此选项会影响下一个伪引用选项 --all 或 --glob，并在处理它们后清除。

--reflog

假装引用日志中提及的所有对象都作为 <commit> 列在命令行上。

--alternate-refs

假装所有在备用仓库中作为引用尖端提及的对象都已在命令行中列出。备用仓库是指其对象目录在 objects/info/alternates 中指定的任何仓库。包含的对象集可以通过 core.alternateRefsCommand 等进行修改。参见 git-config[1]。

--single-worktree

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

--ignore-missing

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

--stdin

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

--quiet

不要向标准输出打印任何内容。这种形式主要是为了让调用者测试退出状态，以查看一系列对象是否完全连接（或不连接）。这比将标准输出重定向到 /dev/null 更快，因为输出无需格式化。

--disk-usage
--disk-usage=human

抑制正常输出；而是打印选定提交或对象在磁盘存储中所使用的字节总和。这等效于将输出通过管道传输到 git cat-file --batch-check='%(objectsize:disk)，但运行速度快得多（尤其是在使用 --use-bitmap-index 时）。关于“磁盘存储”的含义的限制，请参阅 git-cat-file[1] 中的 CAVEATS 部分。如果使用可选值 human，磁盘存储大小将以人类可读的字符串显示（例如 12.24 KiB，3.50 MiB）。

--cherry-mark

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

--cherry-pick

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

例如，如果您有两个分支 A 和 B，通常只列出其中一侧的所有提交的方法是使用 --left-right（参见下面 --left-right 选项描述中的示例）。但是，它会显示从另一分支挑选的提交（例如，“b 上的第 3 次提交”可能从分支 A 挑选而来）。使用此选项，此类成对的提交将从输出中排除。

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

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

当 --pretty 格式不是 oneline 和 reference（原因显而易见）时，这会导致输出包含来自引用日志的两行额外信息。输出中的引用日志指示符可能显示为 ref@{<Nth>}（其中 <Nth> 是引用日志中的逆时间顺序索引）或 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

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

--use-bitmap-index

尝试使用打包位图索引（如果可用）来加速遍历。请注意，当使用 --objects 遍历时，树和二进制对象将不会打印其关联路径。

--progress=<header>

在考虑对象时，在标准错误输出上显示进度报告。每次进度更新时都会打印 <header> 文本。

-z

输出的每个对象及其伴随的元数据不再以换行符分隔，而是使用 NUL 字节分隔。输出以以下形式打印：

<OID> NUL [<token>=<value> NUL]...

附加的对象元数据，例如对象路径或边界对象，使用 <token>=<value> 形式打印。令牌值按原样打印，不进行任何编码/截断。OID 条目从不包含 = 字符，因此用于指示新对象记录的开始。示例：

<OID> NUL
<OID> NUL path=<path> NUL
<OID> NUL boundary=yes NUL
<OID> NUL missing=yes NUL [<token>=<value> NUL]...

此模式仅与 --objects、--boundary 和 --missing 输出选项兼容。

历史简化

有时您只对历史的某些部分感兴趣，例如修改特定 <path> 的提交。但《历史简化》(History Simplification) 有两部分，一部分是选择提交，另一部分是如何进行简化，因为有多种策略可以简化历史。

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

<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 排除在考虑之外的。C 通过 N 进行考虑，但它是 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'。在此过程中，删除是其他父级的祖先或与空树 TREESAME 的根提交的父级，并删除重复项，但要注意永远不要删除我们是 TREESAME 的所有父级。

  • 如果在此父重写之后，C' 是一个根提交或合并提交（具有零或 >1 个父级），一个边界提交，或 !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 被删除，因为它是一个 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 引入的错误污染并且需要修复时，我们可能只想查看 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 不是。

在使用默认模式时，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 重写的第二个父级可以从它们的第一父级到达。这些边被移除，然后提交看起来像与其父级 TREESAME 的单父提交。提交 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 但与其后续父级是 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 选项允许您通过省略未被标签引用的提交来仅查看历史拓扑的概览。提交被标记为 !TREESAME（换句话说，在上述历史简化规则后保留）如果 (1) 它们被标签引用，或者 (2) 它们更改了命令行上给定的路径内容。所有其他提交都被标记为 TREESAME（可能会被简化掉）。

二分查找助手

--bisect

将输出限制为一个提交对象，该对象大致位于包含的和排除的提交之间的一半位置。请注意，坏的二分查找引用 refs/bisect/bad 会被添加到包含的提交中（如果存在），好的二分查找引用 refs/bisect/good-* 会被添加到排除的提交中（如果存在）。因此，假设 refs/bisect/ 中没有引用，如果：

	$ git rev-list --bisect foo ^bar ^baz

输出 midpoint，则以下两个命令的输出

	$ git rev-list foo ^midpoint
	$ git rev-list midpoint ^bar ^baz

的长度大致相同。因此，查找引入回归的更改就简化为二分查找：重复生成和测试新的“中间点”，直到提交链的长度为一。

--bisect-vars

此选项的计算方式与 --bisect 相同，但 refs/bisect/ 中的引用不被使用，并且它输出可供 shell `eval` 执行的文本。这些行会将中间修订的名称分配给变量 bisect_rev，将测试 bisect_rev 后预期要测试的提交数量分配给 bisect_nr，如果 bisect_rev 被证明是好的，则预期要测试的提交数量分配给 bisect_good，如果 bisopsis">bisect_rev 被证明是坏的，则预期要测试的提交数量分配给 bisect_bad，并将当前正在进行二分查找的提交数量分配给 bisect_all。

--bisect-all

此选项输出包含提交和排除提交之间的所有提交对象，并按它们与包含和排除提交的距离排序。refs/bisect/ 中的引用不被使用。距离最远的首先显示。（这是 --bisect 显示的唯一一个。）

这很有用，因为它使得当您因某种原因（例如它们可能无法编译）而想要避免测试某些提交时，可以轻松选择一个好的提交进行测试。

此选项可以与 --bisect-vars 一起使用；在这种情况下，在所有排序的提交对象之后，将显示与单独使用 --bisect-vars 时相同的文本。

提交排序

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

--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 仓库的打包。

--objects

打印列出提交引用的任何对象的对象 ID。--objects foo ^bar 因此意味着“如果我有提交对象 bar 但没有 foo，请将我需要下载的所有对象 ID 发送给我”。另请参阅下面的 --object-names。

--in-commit-order

按提交顺序打印树和二进制对象的 ID。树和二进制对象的 ID 在它们首次被提交引用后打印。

--objects-edge

类似于 --objects，但也会打印以“ - ”字符为前缀的被排除提交的 ID。这被 git-pack-objects[1] 用于构建“瘦”包，该包以基于这些排除提交中包含的对象进行增量化的形式记录对象，以减少网络流量。

--objects-edge-aggressive

类似于 --objects-edge，但它会更努力地查找被排除的提交，代价是增加时间。这用于代替 --objects-edge，为浅层仓库构建“瘦”包。

--indexed-objects

假装索引使用的所有树和二进制对象都已在命令行中列出。请注意，您可能也想使用 --objects。

--unpacked

仅与 --objects 一起使用有用；打印不在包中的对象 ID。

--object-names

仅与 --objects 一起使用有用；打印找到的对象 ID 的名称。这是默认行为。请注意，每个对象的“名称”是模糊的，主要旨在作为打包对象的提示。特别是：标签、树和二进制对象的名称之间没有区别；路径名可能被修改以去除换行符；如果一个对象以不同的名称多次出现，则只显示一个名称。

--no-object-names

仅与 --objects 一起使用有用；不打印找到的对象 ID 的名称。这反转了 --object-names 的行为。此标志允许 git-cat-file[1] 等命令更容易解析输出。

--filter=<filter-spec>

仅与 --objects* 之一一起使用有用；从打印对象列表中省略对象（通常是二进制对象）。<filter-spec> 可以是以下之一：

形式 --filter=blob:none 会省略所有二进制对象。

形式 --filter=blob:limit=<n>[kmg] 会省略大小至少为 n 字节或单位的二进制对象。n 可以为零。后缀 k、m 和 g 可用于表示 KiB、MiB 或 GiB 的单位。例如，blob:limit=1k 与 blob:limit=1024 相同。

形式 --filter=object:type=(tag|commit|tree|blob) 会省略所有不是请求类型的对象。

形式 --filter=sparse:oid=<blob-ish> 使用包含在二进制对象（或二进制对象表达式）<blob-ish> 中的稀疏检出规范，以省略在请求的引用上进行稀疏检出不需要的二进制对象。

形式 --filter=tree:<depth> 会省略所有根树深度 >= <depth> 的二进制对象和树（如果对象位于遍历的提交中的多个深度，则为最小深度）。<depth>=0 不会包含任何树或二进制对象，除非在命令行中（或使用 --stdin 时通过标准输入）明确包含。<depth>=1 将仅包含直接由从 <commit> 可达的提交或明确给定的对象引用的树和二进制对象。<depth>=2 类似于 <depth>=1，同时还包含比明确给定的提交或树再远一个级别的树和二进制对象。

请注意，由于安全原因，已删除从文件系统上的任意路径读取的形式 --filter=sparse:path=<path>。

可以指定多个 --filter= 标志来组合过滤器。仅包含被所有过滤器接受的对象。

形式 --filter=combine:<filter1>+<filter2>+…​<filterN> 也可以用于组合多个过滤器，但这比简单地重复 --filter 标志更难，通常也不是必需的。过滤器通过 + 连接，单个过滤器进行 % 编码（即 URL 编码）。除了 + 和 % 字符外，以下字符是保留字符，也必须进行编码：~!@#$^&*()[]{}\;",<>?'`，以及所有 ASCII 码 <= 0x20 的字符，其中包括空格和换行符。

其他任意字符也可以进行编码。例如，combine:tree:3+blob:none 和 combine:tree%3A3+blob%3Anone 是等效的。

--no-filter

关闭任何先前的 --filter= 参数。

--filter-provided-objects

过滤显式提供的对象列表，否则即使它们不匹配任何过滤器也始终会打印。仅与 --filter= 一起使用有用。

--filter-print-omitted

仅与 --filter= 一起使用有用；打印被过滤器省略的对象列表。对象 ID 以“~”字符为前缀。

--missing=<missing-action>

一个调试选项，用于帮助未来的“部分克隆”开发。此选项指定如何处理缺失对象。

形式 --missing=error 要求如果在遇到缺失对象时 rev-list 停止并报错。这是默认操作。

形式 --missing=allow-any 允许在遇到缺失对象时继续对象遍历。缺失对象将从结果中静默省略。

形式 --missing=allow-promisor 类似于 allow-any，但只允许对象遍历在遇到“预期”的许诺对象缺失时继续。意外的缺失对象将引发错误。

形式 --missing=print 类似于 allow-any，但也会打印缺失对象的列表。对象 ID 以“?”字符为前缀。

形式 --missing=print-info 类似于 print，但还会打印从包含对象推断出的缺失对象的附加信息。所有信息都与缺失对象 ID 在同一行打印，形式为：?<oid> [<token>=<value>]...。包含附加信息的 <token>=<value> 对之间用一个空格（SP）分隔。值以令牌特定的方式编码，但值中包含的空格（SP）或换行符（LF）总是以确保编码结果不包含这两个问题字节的方式表示。每个 <token>=<value> 可以是以下之一：

  • path=<path> 显示从包含对象推断出的缺失对象的路径。包含空格（SP）或特殊字符的路径会根据需要用 C 风格的双引号括起来。

  • type=<type> 显示从包含对象推断出的缺失对象的类型。

如果传递给遍历的一些尖端对象丢失，它们也将被视为丢失，并且遍历将忽略它们。但是，如果无法获取它们的“对象 ID”，将引发错误。

--exclude-promisor-objects

（仅供内部使用。）在许诺边界预过滤对象遍历。这用于部分克隆。这比 --missing=allow-promisor 更强大，因为它限制了遍历，而不仅仅是抑制有关缺失对象的错误。

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

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

--do-walk

覆盖之前的 --no-walk 选项。

提交格式化

使用这些选项，git-rev-list[1] 的行为将类似于更专业的提交日志工具系列：git-log[1]、git-show[1] 和 git-whatchanged[1]

--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>" 选项（如果显示差异输出，此选项也会对其进行修改）来指定前缀的最小长度。

这应该会使使用 80 列终端的人员更容易阅读 "--pretty=oneline"。

--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）中，制表符会被扩展。

--show-signature

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

--relative-date

等同于 --date=relative。

--date=<format>

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

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

--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”格式，后跟 4 位年份，以及时区信息，除非使用本地时区，例如 Thu Jan 1 00:00:00 1970 +0000。

--header

以原始格式打印提交内容；每条记录用 NUL 字符分隔。

--no-commit-header

抑制在指定格式之前打印的包含“commit”和对象 ID 的头行。这对于内置格式无效；仅自定义格式受影响。

--commit-header

覆盖先前的 --no-commit-header。

--parents

同时打印提交的父提交（格式为 "commit parent…​"）。也启用父提交重写，参见上文的 历史简化。

--children

同时打印提交的子提交（格式为 "commit child…​"）。也启用父提交重写，参见上文的 历史简化。

--timestamp

打印原始提交时间戳。

--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>，它将是代替默认字符串显示的文本。

--count

打印一个数字，说明将列出多少个提交，并抑制所有其他输出。当与 --left-right 一起使用时，则打印左右提交的计数，用制表符分隔。当与 --cherry-mark 一起使用时，从这些计数中省略补丁等效的提交，并打印等效提交的计数，用制表符分隔。

美观格式 (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=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]的"CONFIGURATION FILE"（配置文件）章节中的"Values"（值）部分所述。默认情况下，仅当启用日志输出的颜色时（通过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>])

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

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

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

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

      • pointer=<value>：如果 HEAD 指向某个分支，则在 HEAD 和该分支之间显示。默认为 " -> "。

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

    例如，生成不带包裹或标签注释的装饰，并使用空格作为分隔符

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

    %(describe[:<options>])

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

    • tags[=<bool-value>]：除了只考虑带注释的标签，也考虑轻量级标签。

    • abbrev=<number>：不使用缩写对象名称的默认十六进制位数（将根据存储库中的对象数量而变化，默认值为7），而是使用<number>位数，或根据需要使用足够多的位数来形成唯一的对象名称。

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

    • exclude=<pattern>：不考虑匹配给定 glob(7) 模式的标签，不包括 "refs/tags/" 前缀。

    %S

    在命令行上给出的引用名称，通过它到达了提交（如 git log --source），仅适用于 git log

    %e

    编码

    %s

    主题

    %f

    净化后的主题行，适合作为文件名

    %b

    正文

    %B

    原始正文（未回绕的主题和正文）

    %GG

    来自 GPG 的原始验证消息，用于已签名提交

    %G?

    显示"G"表示有效签名，"B"表示无效签名，"U"表示有效但未知有效性的签名，"X"表示已过期的有效签名，"Y"表示由过期密钥制作的有效签名，"R"表示由已撤销密钥制作的有效签名，"E"表示无法检查签名（例如缺少密钥），"N"表示无签名。

    %GS

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

    %GK

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

    %GF

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

    %GP

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

    %GT

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

    %gD

    引用日志选择器，例如，refs/stash@{1}或refs/stash@{2 minutes ago}；其格式遵循-g选项所描述的规则。@之前的部分是命令行上给出的引用名称（因此git log -g refs/heads/master将产生refs/heads/master@{0}）。

    %gd

    缩短的引用日志选择器；与%gD相同，但引用名称部分为了易读性而缩短（因此refs/heads/master仅变为master）。

    %gn

    引用日志身份名称

    %gN

    引用日志身份名称（遵循 .mailmap，参见 git-shortlog[1] 或 git-blame[1]）

    %ge

    引用日志身份电子邮件

    %gE

    引用日志身份电子邮件（遵循 .mailmap，参见 git-shortlog[1] 或 git-blame[1]）

    %gs

    引用日志主题

    %(trailers[:<options>])

    显示由git-interpret-trailers[1]解释的正文尾注。trailers字符串后面可以跟着一个冒号和零个或多个逗号分隔的选项。如果任何选项被多次提供，则以最后一次出现为准。

    • key=<key>：仅显示指定<key>的尾注。匹配不区分大小写，并且尾随冒号是可选的。如果多次给定此选项，则显示匹配任一键的尾注行。此选项会自动启用only选项，以便隐藏尾注块中非尾注行。如果不需要，可以通过only=false禁用。例如，%(trailers:key=Reviewed-by)显示键为Reviewed-by的尾注行。

    • only[=<bool>]：选择是否包含尾注块中的非尾注行。

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

    • unfold[=<bool>]：使其行为如同给定了interpret-trailer的--unfold选项。例如，%(trailers:only,unfold=true)展开并显示所有尾注行。

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

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

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

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

布尔选项接受一个可选值[=<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

示例

  • 打印当前分支可达的提交列表。

    git rev-list HEAD

  • 打印此分支上的提交列表，但不包括上游分支中存在的提交。

    git rev-list @{upstream}..HEAD

  • 格式化提交及其作者和提交消息（另请参见基础命令git-log[1]）。

    git rev-list --format=medium HEAD

  • 格式化提交及其差异（另请参见基础命令git-log[1]，它可以在单个进程中完成此操作）。

    git rev-list HEAD |
git diff-tree --stdin --format=medium -p

  • 打印当前分支上修改了Documentation目录中任何文件的提交列表。

    git rev-list HEAD -- Documentation/

  • 打印您在过去一年中，在任何分支、标签或其他引用上，由您提交的列表。

    git rev-list --author=you@example.com --since=1.year.ago --all

  • 打印当前分支可达的对象列表（即，所有提交及其包含的 blob 和 tree）。

    git rev-list --objects HEAD

  • 比较所有可达对象的磁盘大小，与可从引用日志可达的对象大小，以及总打包大小。这可以告诉您运行git repack -ad是否能减小存储库大小（通过删除不可达对象），以及过期引用日志是否有帮助。

    # reachable objects
git rev-list --disk-usage --objects --all
# plus reflogs
git rev-list --disk-usage --objects --all --reflog
# total disk size used
du -c .git/objects/pack/*.pack .git/objects/??/*
# alternative to du: add up "size" and "size-pack" fields
git count-objects -v

  • 报告每个分支的磁盘大小，不包括当前分支使用的对象。这可以找出导致存储库膨胀的异常值（例如，因为某人不小心提交了大型构建制品）。

    git for-each-ref --format='%(refname)' |
while read branch
do
	size=$(git rev-list --disk-usage --objects HEAD..$branch)
	echo "$size $branch"
done |
sort -n

  • 比较一组引用中分支的磁盘大小，排除另一组。如果您在单个存储库中混合了来自多个远程仓库的对象，这可以显示哪些远程仓库对存储库大小有所贡献（以origin的大小为基准）。

    git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin

GIT

Git[1] 套件的一部分

scroll-to-top