Git

git-rev-list last updated in 2.44.0

名称

git-rev-list 按照时间倒序列出提交对象

概述

git rev-list [<选项>] <提交>… [[--] <路径>…]

描述

列出可以从给定的提交中通过 "父 "链接到达的提交，但不包括可以从前面有"^"的提交中到达的提交。默认情况下，输出结果是按时间顺序倒置的。

你可以把它看成是一个集合操作。从命令行上给出的任何一个提交中可以到达的提交形成一个集合，然后从这个集合中减去任何一个前面带有'^'的提交。剩下的提交内容就是命令的输出结果。其他各种选项和路径参数也可以用来进一步限制结果。

因此，可以执行以下命令：

$ git rev-list foo bar ^baz

意思是 "列出所有可以从’foo’或’bar'，但不能从’baz’到达的提交"。

一个特殊的符号 "<提交 1>…<提交 2>" 可以作为 "^<提交 1> <提交 2>" 的简称。例如，以下两种情况可以互换使用：

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

另一个特殊的符号是 "<提交 1>…<提交 2>"，对合并很有用。由此产生的提交集合是两个操作数之间的对称差。以下两个命令是等价的：

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

-<数>

-n <数量>

--max-count=<数量>

限制输出的提交数量。

--skip=<数量>

在开始显示提交输出之前，跳过’数’的提交。

--since=<日期>

--after=<日期>

显示比某一特定日期更近的提交。

--since-as-filter=<日期>

显示所有比指定日期更近的提交。这将访问该范围内的所有提交，而不是停在第一个比指定日期更早的提交。

--until=<日期>

--before=<日期>

显示超过特定日期的提交。

--max-age=<时间戳>

--min-age=<时间戳>

将提交的结果限制在指定的时间范围内。

--author=<模式>

--committer=<模式>

将提交文件的输出限制在作者/提交人标题行符合指定模式（正则表达式）的文件。如果有多个`--author=<pattern>，则会选择作者符合任何一个给定模式的提交（对于多个--committer=<pattern>`也是如此）。

--grep-reflog=<模式>

将提交文件的输出限制在有符合指定模式（正则表达式）的reflog条目的提交文件。如果有多个 --grep-reflog，则会选择那些 reflog 信息符合任何指定模式的提交。除非使用了`--walk-reflogs`，否则使用此选项是错误的。

--grep=<模式>

将提交结果限制在日志信息与指定模式（正则表达式）相匹配的提交。如果有多个 --grep=<模式>，则会选择那些日志信息与任何指定模式相匹配的提交（但见 --all-match）。

--all-match

将输出的提交限制在符合所有给定`--grep`的提交，而不是至少符合一个的提交。

--invert-grep

限定输出的提交信息与 `--grep=<模式>`指定的模式不匹配。

-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=<数量>

--max-parents=<数量>

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

查找要包含的提交时，在看到合并提交时只跟随第一个父提交。在查看某个特性分支的演变时，该选项可以提供更好的概览，因为合并到特性分支往往只是为了不时地适应上游的更新，而该选项可以让你忽略由合并带来的历史中的单个提交。

--exclude-first-parent-only

在寻找要排除的提交（用'^'）时，在看到合并提交时只跟随第一个父提交。考虑到任意的合并都可以成为有效的主题分支变化，这可以用来查找主题分支中从它与远程分支的分歧点开始的变化集合。

--not

反转 ^ 前缀（或无前缀）对后面所有版本说明符的意义，直到下一个 --not。在 --stdin 之前的命令行中使用时，通过标准输入流传递的修订版本不会受其影响。反之，通过标准输入传递时，命令行上传递的修订版本也不会受其影响。

--all

假设`refs/‘中的所有参考文献，连同`HEAD`一起，在命令行中被列为’<commit>'。

--branches[=<模式>]

假设`refs/heads`中的所有 refs 在命令行中被列为 <commit>。如果给出了'<pattern>'，将分支限制在与给定的shell glob相匹配的分支。如果pattern缺少'?、*'或'[，则末尾的/*'是暗示的。

--tags[=<模式>]

假设`refs/tags`中的所有参考文献在命令行中被列为'<commit>'。如果给出了'<pattern>'，将标签限制在与给定的shell glob相匹配的标签。如果pattern缺少'?、*'或'[，则暗示最后的/*'。

--remotes[=<模式>]

假设`refs/remotes`中的所有 refs 在命令行中被列为 <commit>。如果给出了'<pattern>'，将远程跟踪分支限制在与给定的shell glob相匹配的分支。如果pattern缺少'?、*'或'[，则末尾的/*'是暗示的。

--glob=<通配符模式>

假设所有与shell glob <glob-pattern>相匹配的refs在命令行中被列为<commit>'。前面的’refs/，如果缺少的话会自动预加。如果模式中缺少?、*'或'[，则在结尾处隐含/*'。

--exclude=<通配符模式>

不包括匹配"<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

假设reflogs提到的所有对象都在命令行中被列为`<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

不要打印任何东西到标准输出。这种形式主要是为了让调用者测试退出状态，看看一系列的对象是否完全连接（或没有）。它比将stdout重定向到`/dev/null`要快，因为输出不需要被格式化。

--disk-usage

--disk-usage=human

抑制正常输出；相反，打印所选提交或对象用于磁盘存储的字节数之和。这相当于用管道将输出写入 git cat-file --batch-check='%(objectsize:disk)' ，只是它的运行速度要快得多（尤其是在使用 --use-bitmap-index 时）。参见 git-cat-file[1] 中的 注意事项 部分，了解 “磁盘存储” 的限制。如果使用可选值 human，磁盘存储大小将以人类可读字符串显示（如 12.24 Kib、3.50 Mib）。

--cherry-mark

就像`--cherry-pick`（见下文），但用`=标记同等的提交，而不是省略，用+`标记不同等的提交。

--cherry-pick

当提交的集合有对称差异时，省略任何与 "另一边 "的另一个提交相同的提交。

例如，如果你有两个分支，A 和 B，通常的方法是用`--左—右`列出其中一边的所有提交（见下面关于`--left-right`选项的描述）。然而，它显示的是从另一个分支中偷梁换柱的提交（例如，'3rd on b' 可能是从分支 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

不走提交祖先链，而走从最近的提交到更早的提交的reflog条目。使用这个选项时，你不能指定要排除的提交（也就是说，不能使用'^commit'、'commit1…commit2’和’commit1/…commit2’的符号）。

在 --pretty 格式下，除了 oneline 和 reference （由于明显的原因），这将导致输出有两行额外的信息来自引用日志。输出中的引用日志代号可以显示为 ref@{Nth}（其中 Nth 是引用日志中的逆序索引）或 ref@{timestamp} （带有该条目的时间戳），取决于一些规则：

如果起点被指定为`ref@{Nth}`，显示索引格式。
如果起点被指定为`ref@{now}`，显示时间戳格式。
如果两者都没有使用，但在命令行中给出了`--date`，则按照`--date`所要求的格式显示时间戳。
否则，显示索引格式。

在`--pretty=oneline`下，提交信息的前缀是同一行中的这些信息。这个选项不能与 `--reverse`结合使用。参见 git-reflog[1]。

在`--pretty=reference`下，这些信息将完全不显示。

--merge

在合并失败后，显示触及有冲突的文件且不存在于所有要合并的头的参考文件。

--boundary

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

--use-bitmap-index

尝试使用包位图索引（如果有的话）来加快遍历的速度。注意，当使用`--objects` 选项进行遍历时，目录树和 blobs 不会打印出它们的相关路径。

--progress=<头信息>

在考虑对象时在stderr上显示进度报告。`<标题>`文本将在每次进度更新时打印。

简化历史

有时你只对历史的一部分感兴趣，例如修改某个<路径>的提交。但 "历史简化 "有两部分，一部分是选择提交，另一部分是如何做，因为有各种策略来简化历史。

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

<paths>: 修改给定<路径>的提交会被选中。
--simplify-by-decoration: 被某个分支或标签引用的提交被选中。

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

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

默认模式: 将历史简化为解释树的最终状态的最简单的历史。最简单的原因是，如果最终结果相同，它会修剪一些侧枝（即合并具有相同内容的分支）
--show-pulls: 包括默认模式下的所有提交，但也包括任何与第一个父分支不相干但与后来的父分支相干的合并提交。这种模式有助于显示 "首次引入 "某个分支的合并提交。
--full-history: 与默认模式相同，但不修剪一些历史记录。
--dense: 只显示所选的提交，再加上一些才有意义的历史。
--sparse: 简化历史中的所有提交都会显示出来。
--simplify-merges: 为`--full-history`增加了一个选项，可以从结果的历史中删除一些不必要的合并，因为没有选定的提交对这次合并有贡献。
--ancestry-path[=<提交>]: 如果给定了一个要显示的提交范围（例如 提交1..提交2 或 提交2 ^-提交1 ），则只会显示该范围内属于 <提交> 的祖先、<提交> 的后代或 <提交> 本身的提交。如果没有指定提交，则使用 提交1（范围中排除的部分）作为 <提交>。可以多次传递；如果是这样，如果某个提交是所给定提交中的任何一个，或者是其中一个提交的祖先或后代，则该提交将被包括在内。

以下是更详细的解释。

假设你指定了 foo 作为 <路径>。我们将把修改 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`在`P`上添加了`side，`Q`与`P`是同源，但与`Y`不是同源。

rev-list`在历史中倒退，根据是否使用--full-history`和/或父代重写（通过`--parents`或`--children`），包括或排除提交。以下设置是可用的。

默认模式

如果提交的内容与任何父类不相干，则被包括在内（当然这一点可以改变，见下面的`--sparse`）。如果该提交是一个合并，并且它与一个父类是同源的，则只跟随该父类。 (即使有几个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。 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。

除了上述设置外，你还可以改变 TRESAME 是否会影响收录：

--dense

如果不与任何父类有TREESAME关系，则包括走过的承诺。

--sparse

所有走过的提交都包括在内。

请注意，如果没有`--full-history`，这仍然可以简化合并：如果父代之一是TREESAME，我们只跟随这个父代，所以合并的其他方面永远不会被走。

--simplify-merges

首先，按照`--full-history`与父级改写的相同方式建立一个历史图（见上文）。

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

将 "C "设为 "C"。
将`C'的每个父类`P'替换成其简化的`P'。在这个过程中，放弃那些是其他父类的祖先的父类，或者是根部提交TREESAME的空树，并删除重复的父类，但注意不要放弃所有我们是TREESAME的父类。
如果在这次父级改写之后，‘C’`是一个根或合并提交（有0个或>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[=<提交>]

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

作为一个用例，请考虑以下提交历史：

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

有规律的 "D…M "会计算出作为`M`的祖先的提交集合，但不包括作为`D`的祖先的提交。这对了解`M’的历史在`D’之后发生了什么很有用，也就是说`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 `的修改，因此与其中任何一个都不是同源的。然而，合并提交`R`是通过忽略`M`处的`file.txt`的内容，而只采用`X`处的`file.txt`的内容而产生的。因此，`R`与`X`是同源的，但不是`M。最后，创建`N’的自然合并决议是取`file.txt`在`R’的内容，所以`N’与`R`是同源的，但不是`C`。合并提交的 O 和 P 与它们的第一代父母是同源的，但与它们的第二代父母 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

除了在默认历史中显示的提交之外，还要显示每一个与第一个父本不相同但与后来的父本相同的合并提交。

当一个合并提交被 --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（会被简化掉）。

剖腹产助手

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

的长度大致相同。因此，找到引入回归的变化就变成了一个二进制搜索：反复生成和测试新的 "中点"，直到提交链的长度为1。

--bisect-vars

这与`--bisect`的计算方法相同，只是不使用`refs/bisect/中的参考文献，而且输出的文本可以被shell评估。这几行将把中点修订的名称分配给变量`bisect_rev，并把`bisect_rev`测试后的预期提交数分配给`bisect_nr`。如果`bisect_rev’结果是好的，预计测试的提交数量为`bisect_good'，如果`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 因此意味着 '给我发送所有我需要下载的对象ID，如果我有提交对象_bar_但没有_foo_的话'。另请参阅下面的 --object-names 选项。
--in-commit-order: 按照提交的顺序打印树和blob的id。树和blob的id会在它们第一次被提交者引用后打印。
--objects-edge: 类似于 --objects，但也会打印被排除的提交物的 ID，前缀为 ‘-’'字符。这被 git-pack-objects[1] 用来建立一个 "瘦身 "包，它基于这些被排除的提交中包含的对象，以删除的形式记录对象，以减少网络流量。
--objects-edge-aggressive: 类似于 --objects-edge，但它更努力地寻找被排除的提交，代价是增加时间。它被用来代替`--objects-edge`，为浅层仓库建立 "薄 "的包。
--indexed-objects: 假设索引使用的所有树和blobs都列在命令行中。注意，你可能也想使用`--objects`。
--unpacked: 只对 --objects 有用；打印不在包中的对象 ID。
--object-names: 只对 --objects 有用；打印找到的对象ID的名称。这是默认的行为。注意，每个对象的 "名字" 是模糊的，主要是作为打包对象的提示。特别是：标签、树和二进制文件的名字不作区分；路径名称可以被修改以删除换行；如果一个对象会以不同的名字出现多次，则只显示一个名字。
--no-object-names: 只对 --objects 有用；不打印找到的对象 ID 的名称。这与 --object-names 相反。这个标志允许输出更容易被 git-cat-file[1] 等命令解析。
--filter=<过滤器定义>: 只对其中一个 --objects* 选项有用；从打印对象列表中省略对象（通常是 blobs）。 <过滤规则> 可以是下列之一：

'--filter=blob:none’的形式可以省略所有的blob。

格式 --filter=blob:limit=<n>[kmg] 会忽略大小至少为 n 字节或单位的 blob。后缀 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（或 blob 表达式）<blob-ish> 中包含的稀疏检出规范，以省略在请求的引用上进行稀疏检出时不需要的 blob。

--filter=tree:<深度> 的形式省略了所有从根树开始深度 >=<深度>（如果一个对象在所穿越的提交中位于多个深度，则为最小深度）的blobs和目录树。<深度>=0 将不包括任何目录树或 blobs，除非在命令行中明确包括（或使用 --stdin 选项时的标准输入）。<深度>=1 将只包括由 <提交> 或明确指定的对象所能到达的提交直接引用的目录树和 blobs。<深度>=2 与 <深度>=1 类似，同时也包括从明确给出的提交或目录树中移出的多一级的目录树和 blobs。

注意，出于安全原因，想要从文件系统上的任意路径读取的'--filter=sparse:path=<path>'形式已经被放弃了。

可以指定多个'--filter=' 标志来组合过滤器。只有那些被每个过滤器接受的对象才会被包括在内。

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

其他任意的字符也可以被编码。例如，'combined:tree:3+blob:none’和’combined:tree%3A3+blob%3Anone’是等同的。
--no-filter: 关掉之前的任何`--filter=`参数。
--filter-provided-objects: 过滤明确提供的对象的列表，否则，即使它们不符合任何过滤器，也会被打印出来。只对`--filter=`有用。
--filter-print-omitted: 只对`--filter=有用；打印出被过滤器省略的对象的列表。对象ID的前缀是`~''字符。
--missing=<缺失行为>: 一个调试选项，帮助未来的 "部分克隆 "开发。这个选项指定了如何处理丢失的对象。

形式'--missing=error’要求rev-list在遇到丢失的对象时以错误方式停止。这是默认动作。

'--missing=allow-any’的形式将允许在遇到缺失对象时继续进行对象遍历。缺少的对象将被默默地从结果中省略掉。

'--missing=allow-promisor’的形式与’allow-any’相似，但只允许对预期的promisor缺失对象继续进行遍历。意外的缺失对象将引发一个错误。

'--missing=print’的形式与’allow-any’相似，但也会打印出遗失对象的列表。对象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]，linkgit:git-show[1]，和linkgit:git-whatchanged[1]

--pretty[=<格式>]
--format=<格式>: 以指定的格式打印提交日志的内容，其中'<format>'可以是’oneline'、short、medium、full、fuller、reference、email、raw、format:<string>'和’tformat:<string>'之一。当<format>'不是上述任何一种，并且其中有'%placeholder’时，它的作用就像给出'--pretty=tformat:<format>'一样。

参见 "PRETTY FORMATS "部分，了解每种格式的一些额外细节。当'=<格式>'部分被省略时，它默认为’中等'。

注意：你可以在版本库配置中指定默认的漂亮格式（见git-config[1]）。
--abbrev-commit: 不要显示完整的40字节的十六进制提交对象名称，而是显示一个前缀，以唯一的方式命名该对象。 "--abbrev=<n>"选项可以用来指定前缀的最小长度（如果显示的话，它也会修改diff输出）。

这应该使"--pretty=oneline "对于使用80列终端的人来说更容易阅读。
--no-abbrev-commit: 显示完整的40字节十六进制的提交对象名称。这否定了`--abbrev-commit`，无论是明确的还是由其他选项如"--oneline "暗示的。它还覆盖了`log.abbrevCommit`变量。
--oneline: 这是"--pretty=oneline --abbrev-commit "的简写，一起使用。
--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个空格（即 "中"，这是默认的，"全"，和 "更全"）。
--show-signature: 通过将签名传递给 gpg --verify 来检查已签名的提交对象的有效性，并显示输出。

--relative-date

`--date=relative`的同义词。

--date=<格式>

只对以人类可读格式显示的日期生效，例如使用`--pretty`时。log.date`配置变量为日志命令的--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 中，%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。

--header

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

--no-commit-header

抑制包含“提交”的标题行和在指定格式之前打印的对象 ID。这对内置格式没有影响；只有自定义格式会受到影响。

--commit-header

覆盖之前的 --no-commit-header 选项。

--parents

也可以打印提交的父类（以 "提交父类… "的形式）。也可以启用父级改写，见上面的 "历史简化"。

--children

同时打印提交的子项（以 "提交子项… "的形式）。也可以启用父级改写，见上面的 "历史简化"。

--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[=<阻隔>]

如果不使用 --graph，所有的历史分支都会被压扁，这就很难看出两个连续的提交并不属于一个线性分支。在这种情况下，该选项会在它们之间设置一个障碍。如果指定了"<barrier>"，就会显示这个字符串，而不是默认的。

--count

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

漂亮的格式

如果提交是一个合并，并且如果pretty-format不是 "oneline"、"email "或 "raw"，那么在 "Author: "一行之前会插入一个附加行。这一行的开头是 "Merge:这一行以 "Merge: "开头，并打印出祖先提交的哈希值，用空格分隔。请注意，如果你限制了你的历史视图，那么列出的提交不一定是*直接*父级提交的列表：例如，如果你只对与某个目录或文件有关的修改感兴趣。

有几种内置的格式，你可以通过将 pretty.<名称> 配置选项设置为另一种格式名称或 format: 字符串来定义额外的格式，如下所述（见 git-config[1] ）。下面是内置格式的细节：

oneline
```
<哈希值> <标题行>
```
这个设计是为了尽可能的紧凑。

short

承诺<hash>
作者。<作者>的情况

<标题行>

medium

commit <哈希值>
Author: <作者>
Date:   <提交日期>

<标题行>

<完整的提交信息

full

承诺<hash>
作者。< Author>
承诺。<committer>（提交者）。

<标题行>

<完整的提交信息

fuller

commit <哈希值>
Author:     <作者>
AuthorDate: <作者提交日期>
Commit:     <提交者>
CommitDate: <提交者提交日期>

<标题行>

<完整的提交信息

‘引用’
```
<缩写哈希值>（<标题行>，<简短的作者日期>）
```
这种格式用于在提交信息中引用另一个提交，与`--pretty='format:%C(auto)%h (%s, %ad)'相同。默认情况下，日期的格式为`--date=short`，除非明确指定其他`--date`选项。与任何带有格式占位符的`format:一样，其输出不受其他选项的影响，如--decorate`和`--walk-reflogs`。

email

From <哈希> <日期>
From: <作者>
Date: <作者提交日期>
Subject: [PATCH] <标题行>

<完整的提交信息

mboxrd

和 "email "一样，但提交信息中以 "From "开头的行（前面有零个或多个">"）用">"引出，这样就不会被混淆为开始了一个新的提交。
raw

原始 "格式显示的是整个提交对象中存储的内容。值得注意的是，无论是否使用了 --abbrev 或 --no-abbrev，哈希值都会被完整地显示出来，而’parent’信息会显示真正的父级提交，不会考虑移花接木或历史简化。注意，这种格式会影响提交的显示方式，但不会影响diff的显示方式，比如用`git log --raw`来显示。要获得原始差异格式的完整对象名称，请使用`--no-abbrev`。
format:<格式字符串>

format:<格式字符串 格式允许你指定要显示的信息。它的工作原理有点像 printf 格式，但有一个明显的例外，那就是换行符是 %n 而不是 \n。

例如，format: "The author of %h was %an, %ar%nThe title was >>%s<<%n" 会显示这样的内容：
```
fe6e0ee的作者是Junio C Hamano, 23小时前
标题是 >>t4119: 测试传统diff输入的自动计算-p<n>。
```
占位符是：
- 占位符，可扩展为一个字面字符：
  
  %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
  
  尊重 .mailmap 作者的本地部分（参见 %al ），参见 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
  
  ref名称，就像git-log[1]的—decorate选项。
  
  %D
  
  没有"（"、"）"包装的参考文献名称。
  
  %(decorate[:<选项>])
  
  自定义装饰的引用名称。decorate 字符串后面可以是冒号和零个或多个以逗号分隔的选项。选项值可能包含字面格式化代码。由于逗号（%x2C）和结尾括号（%x29）在选项语法中的作用，因此必须使用这些代码。
  
  prefix=<值>：显示在引用名称列表之前。默认为 " ("。
  
  suffix=<值>：显示在引用名称列表之后。默认为 ")"。
  
  separator=<值>：显示在引用名称之间。默认为 ", "。
  
  point=<值>：显示在 HEAD 和其指向的分支（如果有）之间。默认为 " -> "。
  
  tag=<值>：显示在标记名称之前。默认为 "tag: "。
例如，制作不带包装或标签注释的装饰，并用空格作为分隔符：

+ %(decorate:prefix=,suffix=,tag=,separator= )
%(describe[:<选项>])
人类可读的名字，像git-describe[1]；空字符串表示不可描述的提交。 `describe`字符串后面可以有冒号和零个或多个逗号分隔的选项。当标签同时被添加或删除时，描述可能不一致。
tags[=<bool-value>]：不仅考虑带注释的标签，还考虑轻量级标签。

abbrev=<数量>：不使用缩写对象名称的默认十六进制位数（根据仓库中对象的数量而变化，默认为 7 位），而是使用 <数量> 的位数，或根据需要的位数来组成唯一的对象名称。

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

reflog选择器，例如，refs/stash@{1}`或`refs/stash@{2分钟前}；其格式遵循`-g`选项的规则。@'前面的部分是命令行上给出的参考文献名称（所以`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[:<选项>])
显示由 git-interpret-trailers[1] 解释的正文的为主。trailers 字符串后面可以有冒号和零个或多个逗号分隔的选项。如果任何选项被多次提供，则最后出现的选项获胜。
key=<键>：只显示具有指定密钥的为主。匹配是不分大小写的，后面的冒号是可选的。如果多次给出选项，则显示与任何键匹配的为主行。该选项自动启用 only 选项，使拖车块中的非尾注行被隐藏。如果不希望这样，可以用 only=false 禁用。例如，%(trailers:key=Reviewed-by) 显示键为 Reviewed-by 的拖车行。

only[=<布尔值>] ：选择是否应该包括来自尾注块的非尾注行。

separator=<切片>：指定插入在尾注行之间的分隔符。如果不使用该选项，则每行以换行符结束。字符串 <切片> 可以包含上述字面格式化代码。要使用逗号作为分隔符，必须使用 %x2C，否则会被解析为下一个选项。例如，%(trailer:key=Ticket,separator=%x2C ) 显示所有关键字为 "Ticket" 的尾注行，并用逗号和空格分隔。

unfold[=<布尔值>]：使它的行为就像 interpret-trailer 的 --unfold 选项被给出一样。例如，`%(trailers:only,unfold=true)`会展开并显示所有的尾注行。

keyonly[=<布尔值>]：只显示尾注的关键部分。

valueonly[=<布尔值>]：只显示尾注的值部分。

key_value_separator=<切片>：指定在尾注行之间插入一个分隔符。当这个选项没有给出时，每个尾注的键值对都用 ": " 分开。否则，它的语义与上面的 separator=<切片> 相同。

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

布尔选项接受一个可选的值`[=<布尔值>]。`true, false, on, `off`等值都可以接受。参见git-config[1]中 “示例” 的 “布尔” 子章节。如果一个布尔选项没有给出值，它就被启用。

如果你在占位符的'%后面加了一个`+（加号），当且仅当占位符扩展为一个非空字符串时，在扩展前会立即插入换行符。

如果你在占位符的'%后面加了一个`-（减号），如果且仅当占位符扩展为空字符串时，紧接着扩展前的所有连续换行将被删除。

如果你在占位符的'%'后面加了一个``（空格），当且仅当占位符扩展到一个非空字符串时，空格就会紧接着插入扩展。

t格式:

tformat: 格式的工作原理与 format: 完全一样，只是它提供了 “终止符” 语义，而不是 “分隔符” 语义。换句话说，每个提交都附加了信息结束符（通常是换行符），而不是在条目之间放置一个分隔符。这意味着单行格式的最后一个条目将正确地以新行结束，就像 “单行” 格式那样。比如说：
```
$ 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
```
打印可从当前分支到达的对象列表（即所有提交及其包含的 blobs 和目录树）。
```
git rev-list --objects HEAD
```
比较所有可到达对象的磁盘大小、可从引用日志到达的对象的磁盘大小以及打包后的总大小。这可以告诉你运行 git repack -ad 是否会减少仓库的大小（通过丢弃无法访问的对象），以及过期的引用日志是否会有帮助。
```
# 可达对象
git rev-list --disk-usage --objects --all
# 加上 reflog
git rev-list --disk-usage --objects --all --reflog
# 所有占用的磁盘空间
du -c .git/objects/pack/*.pack .git/objects/??/*
# 切换到 du: 将 "size" 和 "size-pack" 字段合计
git count-objects -v
```
报告每个分支的磁盘大小，不包括当前分支使用的对象。这样就能发现导致仓库大小臃肿的异常值（例如，因为有人不小心提交了大容量的构建工件）。
```
git for-each-ref --format='%(引用名)' |
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[1] 文档

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands

名称

概述

描述

选项