你可以把它看成是一个集合操作。从命令行上给出的任何一个提交中可以到达的提交形成一个集合，然后从这个集合中减去任何一个前面带有'^'的提交。 剩下的提交内容就是命令的输出结果。 其他各种选项和路径参数也可以用来进一步限制结果。
因此，可以执行以下命令：
$ git log foo bar ^baz
意思是 "列出所有可以从’foo’或’bar'，但不能从’baz’到达的提交"。
一个特殊的符号 "
<提交 1>
…
<提交 2>
" 可以作为 "^
<提交 1>
<提交 2>
" 的简称。例如，以下两种情况可以互换使用：
$ git log origin..HEAD
$ git log HEAD ^origin
另一个特殊的符号是 "
<提交 1>
…
<提交 2>
"，对合并很有用。 由此产生的提交集合是两个操作数之间的对称差。 以下两个命令是等价的：
$ git log A B --not $(git merge-base --all A B)
$ git log A...B
该命令采用适用于
git-rev-list[1]
命令的选项来控制显示的内容和方式，以及适用于
git-diff[1]
命令的选项来控制每次提交引入的更改的显示方式。
--decorate[=short|full|auto|no]
打印显示的任何提交的引用名称。如果指定了 "short"，则不会打印引用名称的前缀 "refs/heads/"、"refs/tags/" 和 "refs/remotes/"。如果指定了 "full"，将打印完整的引用名称（包括前缀）。如果指定了 "auto"，则如果输出是发送到终端，则显示引用名称，就如同指定了"short"一样，否则不显示引用名称。选项
--decorate
是
--decorate=short
的简写。如果配置了
log.decorate
的配置值，默认为配置值，否则为 "auto"。
--decorate-refs=<pattern>
--decorate-refs-exclude=<pattern>
对于每个候选引用，在以下情况下不要将其用于装饰（decorate）：若它与`--decorate-refs-exclude`指定的任何模式匹配，或者若它不与`--decorate-refs`指定的任何模式匹配。配置选项`log.excludeDecoration`允许从装饰中排除引用，但是在`log.excludeDecoration`中的匹配项将被`--decorate-refs`模式中的显式指定所覆盖。
如果没有给出这些选项或配置设置中的任何一个，那么如果引用与
HEAD
、
refs/heads/
、
refs/remotes/
、
refs/stash/
或
refs/tags/
匹配，则使用引用作为装饰。
--clear-decorations
当指定了该选项时，它会清除所有先前的
--decorate-refs
或
--decorate-refs-exclude
选项，并放宽默认的装饰过滤器以包括所有引用。如果配置值
log.initialDecorationSet
设置为
all
，则假定使用此选项。
--source
打印出通过命令行给定的引用名称，以便触及每个提交。
--[no-]mailmap
--[no-]use-mailmap
使用 mailmap 文件将作者和提交者的名称和电子邮件地址映射到规范的真实名称和电子邮件地址。请参阅
git-shortlog[1]
。
--full-diff
如果不使用此标志，
git
log
-p
<path>
...
将显示与指定路径相关的提交，并显示关于相同指定路径的差异。使用此标志，将显示与指定路径相关的提交的完整差异；这意味着 "<path>…" 将仅限定提交，并不限定这些提交的差异。
请注意，这会影响所有基于差异的输出类型。例如：由
--stat
等产生的输出。
--log-size
在每个提交的输出中包含一行 ``log size <number>"" ，其中 <number> 是该提交消息的字节长度。旨在通过允许工具预先分配空间，加快从
git
log
输出中读取日志消息的工具的速度。
-L<起始>,<结束>:<文件>
-L :<函数名称>:<文件>
追踪由
<起始>,<结束>
给出的行的范围，或由函数名称重合词
<函数名称>
给出的行的演变，在
<文件>'中 。你不能给出任何路径规范限制条件。 目前这只限于从一个修订版开始的行走，也就是说，你只能给出零或一个正的修订版参数，而且 '<起始>
和
<结束>
（或
<函数名称>
）必须存在于起始修订版中。 你可以多次指定这个选项。包含
--patch
选项。 补丁输出可以用
--no-patch
来抑制，但其他差异格式（即
--raw
、
--numstat
、
--shortstat
、
--dirstat
、
--summary
、
--name-only
、
--name-status
、
--check
）目前没有实现。
<开始>
和
<结束>
可以采取这些形式之一：
<revision-range>
仅显示指定修订范围内的提交。当没有指定 <revision-range> 时，默认为
HEAD
（即导致当前提交的整个历史记录）。
origin..HEAD
指定从当前提交（即
HEAD
）可达的所有提交，但不包括从
origin
可达的提交。有关拼写 <revision-range> 的完整列表，请参阅
gitrevisions[7]
的 "Specifying Ranges" 部分。
[--] <path>…
只显示那些足以解释符合指定路径的文件是如何形成的提交。 有关细节和其他简化模式，请参见下面的’历史简化'。
当出现混淆时，路径可能需要以`--`为前缀，以便将其与选项或修订范围分开。
使用更多的选项通常会进一步限制输出（例如，
--since=<date1>`限制在比
<date1>
新的提交，与
--grep=<pattern>
一起使用会进一步限制在日志信息中有一行符合
<pattern>`的提交），除非另有说明。
请注意，这些都是在提交排序和格式化选项之前应用的，如
--reverse
。
-n <数量>
--max-count=<数量>
限制输出的提交数量。
--skip=<数量>
在开始显示提交输出之前，跳过’数’的提交。
--since=<日期>
--after=<日期>
显示比某一特定日期更近的提交。
--since-as-filter=<日期>
显示所有比指定日期更近的提交。这将访问该范围内的所有提交，而不是停在第一个比指定日期更早的提交。
--until=<日期>
--before=<日期>
显示超过特定日期的提交。
--author=<模式>
--committer=<模式>
将提交文件的输出限制在作者/提交人标题行符合指定模式（正则表达式）的文件。 如果有多个`--author=<pattern>
，则会选择作者符合任何一个给定模式的提交（对于多个
--committer=<pattern>`也是如此）。
--grep-reflog=<模式>
将提交文件的输出限制在有符合指定模式（正则表达式）的reflog条目的提交文件。如果有多个
--grep-reflog
，则会选择那些 reflog 信息符合任何指定模式的提交。 除非使用了`--walk-reflogs`，否则使用此选项是错误的。
--grep=<模式>
将提交结果限制在日志信息与指定模式（正则表达式）相匹配的提交。 如果有多个
--grep=
<模式>
，则会选择那些日志信息与任何指定模式相匹配的提交（但见
--all-match
）。
当
--notes
生效时，笔记中的信息被匹配，就像它是日志信息的一部分。
--all-match
将输出的提交限制在符合所有给定`--grep`的提交，而不是至少符合一个的提交。
--invert-grep
限定输出的提交信息与 `--grep=<模式>`指定的模式不匹配。
--regexp-ignore-case
匹配正则表达式的限制模式，不考虑字母大小写。
--basic-regexp
将限制性模式视为基本的正则表达式；这是默认的。
--extended-regexp
将限制性模式视为扩展的正则表达式，而不是默认的基本正则表达式。
--fixed-strings
将限制性模式视为固定字符串（不要将模式解释为正则表达式）。
--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
查找要包含的提交时，在看到合并提交时只跟随第一个父提交。 在查看某个特性分支的演变时，该选项可以提供更好的概览，因为合并到特性分支往往只是为了不时地适应上游的更新，而该选项可以让你忽略由合并带来的历史中的单个提交。
这个选项也改变了合并提交的默认差异格式为
first-parent
，详见
--diff-merges=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
在看到输入中无效的对象名称时，假装没有给出坏的输入。
--bisect
假设坏的二分法参考文献`refs/bisect/bad`被列出，并且在命令行中假设它后面是`--not`和好的二分法参考文献`refs/bisect/good-*`。
--stdin
除从命令行获取参数外，还可从标准输入读取参数。它接受提交和伪选项，如
--all
和
--glob=
。当看到
--
分隔符时，下面的输入将被视为路径并用于限制结果。通过标准输入读取的
--not
等标志只适用于以相同方式传递的参数，不会影响后续的命令行参数。
--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`。
--walk-reflogs
不走提交祖先链，而走从最近的提交到更早的提交的reflog条目。 使用这个选项时，你不能指定要排除的提交（也就是说，不能使用'^commit'、'commit1…commit2’和’commit1/…commit2’的符号）。
With
--pretty
format other than
oneline
and
reference
(for obvious reasons), this causes the output to have two extra lines of information taken from the reflog. The reflog designator in the output may be shown as
ref@{
<Nth>
}
(where
<Nth>
is the reverse-chronological index in the reflog) or as
ref@{
<timestamp>
}
(with the
<timestamp>
for that entry), depending on a few rules:
--merge
显示在范围
HEAD...
<其他>
中触及冲突路径的提交，其中
<其他>
是
MERGE_HEAD
、
CHERRY_PICK_HEAD
、
REVERT_HEAD
或
REBASE_HEAD
中第一个存在的伪引用。仅在索引中有未合并条目时有效。这个选项可以在解决三向合并中的冲突时用来显示相关的提交。
--boundary
输出排除的边界提交。边界提交的前缀是"-"。
--ancestry-path[=<提交>]
When given a range of commits to display (e.g.
commit1..commit2
or
commit2 ^commit1
), and a commit <commit> in that range, only display commits in that range that are ancestors of <commit>, descendants of <commit>, or <commit> itself. If no commit is specified, use
commit1
(the excluded part of the range) as <commit>. Can be passed multiple times; if so, a commit is included if it is any of the commits given or if it is an ancestor or descendant of one of them.
假设你指定了
foo
作为 <路径>。 我们将把修改
foo
的提交称为 !TREESAME，其余的称为 TREESAME。 (在为
foo
过滤的差异中，它们看起来分别是不同的和相同的。）
在下文中，我们将始终引用同一个历史实例来说明简化设置之间的差异。 我们假设你在这个提交图中过滤的是一个文件
foo
：
.-A---M---N---O---P---Q
/ / / / / /
I B C D E Y
\ / / / / /
`-------------' X
历史 A---Q 的横线被认为是每次合并的第一个父本。 这些提交是：
如果提交的内容与任何父类不相干，则被包括在内（当然这一点可以改变，见下面的`--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
。
所有走过的提交都包括在内。
请注意，如果没有`--full-history`，这仍然可以简化合并：如果父代之一是TREESAME，我们只跟随这个父代，所以合并的其他方面永远不会被走。
--simplify-merges
首先，按照`--full-history`与父级改写的相同方式建立一个历史图（见上文）。
然后根据以下规则将每个提交的
C
简化为最终历史中的替换
C
：
将`C'
的每个父类`P'替换成其简化的`P'
。 在这个过程中，放弃那些是其他父类的祖先的父类，或者是根部提交TREESAME的空树，并删除重复的父类，但注意不要放弃所有我们是TREESAME的父类。
如果在这次父级改写之后，‘C’`是一个根或合并提交（有0个或>1个父级），一个边界提交，或！TREESAME，那么它将被保留。 否则，它将被替换为其唯一的父类。
有规律的 "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
我们也可以用`--ancestry-path=D`来代替`--ancestry-path`，这在应用于’D…M’范围时意思相同，只是更加明确。
如果我们感兴趣的是这个范围内的某个主题，以及受该主题影响的所有提交，我们可能只想查看祖先路径中包含该主题的`D…M`子集。 因此，以`--ancestry-path=H D…M`为例，会形成以下结果：
C---G---H---I---J
而`--ancestry-path=K D…M`会形成以下结果
K---------------L--M
在这个例子中，假设`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`的修改 "拉 "进了主分支。
如果使用`--topo-order`，它们会显示8 6 5 3 7 4 2 1（或8 7 4 2 6 5 3 1）；一些较早的提交会显示在较新的提交之前，以避免显示两个平行开发轨道的提交混在一起。
--reverse
以相反的顺序输出选择显示的提交（见上面的提交限制部分）。不能与`--walk-reflogs`结合使用。
--no-walk[=(sorted|unsorted)]
只显示给定的提交，但不遍历其祖先。 如果指定了范围，这一点就没有影响。如果给了参数 unsorted，提交会按照命令行上的顺序显示。否则（如果 sorted 或者没有给出参数），提交将按照提交时间的倒序显示。 不能与 --graph 选项结合使用。
--do-walk
覆盖之前的 --no-walk 。
--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个空格（即 "中"，这是默认的，"全"，和 "更全"）。
--notes[=<引用>]
在显示提交日志信息时，显示注释提交的说明（见git-notes[1]）。 这是`git log`、git show`和`git whatchanged`命令的默认设置，当命令行中没有给出--pretty`、--format`或--oneline`选项时。
默认情况下，显示的注释来自于`core.notesRef`和`notes.displayRef`变量（或相应的环境覆盖）中列出的注释参考。更多细节见git-config[1]。
有了一个可选的 <引用> 参数，就可以使用引用来寻找要显示的笔记。 当引用以 refs/notes/ 开头时，可以指定完整的引用名称；当它以 notes/ 开头时， refs/ ，否则 refs/notes/ 前缀，形成引用的全名。
多个—音符选项可以组合起来，控制哪些音符被显示。例如。"--notes=foo "将只显示来自 "refs/notes/foo "的注释；"--notes=foo --notes "将同时显示来自 "refs/notes/foo "和默认注释的注释。
--no-notes
不显示注释。这否定了上面的`--notes`选项，因为它重新设置了显示注释的注释列表。 选项按照命令行给出的顺序进行解析，因此，例如"--notes --notes=foo --no-notes --notes=bar "将只显示来自 "refs/notes/bar "的注释。
--show-notes-by-default
显示默认备注，除非给出了显示特定备注的选项。
--show-notes[=<引用>]
--[no-]standard-notes
这些选项已被废弃。请使用上面的 --notes/--no-notes 选项来代替。
--show-signature
通过将签名传递给 gpg --verify 来检查已签名的提交对象的有效性，并显示输出。
--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。
在输出的左手边绘制基于文本的提交历史图表。 这可能会导致在提交之间打印出额外的行，以便正确地绘制图形历史。 不能与`--no-walk`结合使用。
这可以使父代改写，见上面的’历史简化'。
这意味着默认情况下是`--topo-order`选项，但也可以指定`--date-order`选项。
--show-linear-break[=<阻隔>]
如果不使用 --graph，所有的历史分支都会被压扁，这就很难看出两个连续的提交并不属于一个线性分支。在这种情况下，该选项会在它们之间设置一个障碍。如果指定了"<barrier>"，就会显示这个字符串，而不是默认的。
如果提交是一个合并，并且如果pretty-format不是 "oneline"、"email "或 "raw"，那么在 "Author: "一行之前会插入一个附加行。 这一行的开头是 "Merge:这一行以 "Merge: "开头，并打印出祖先提交的哈希值，用空格分隔。 请注意，如果你限制了你的历史视图，那么列出的提交不一定是*直接*父级提交的列表：例如，如果你只对与某个目录或文件有关的修改感兴趣。
有几种内置的格式，你可以通过将 pretty.<名称> 配置选项设置为另一种格式名称或 format: 字符串来定义额外的格式，如下所述（见 git-config[1] ）。下面是内置格式的细节：
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>。
占位符是：
%C(…)
颜色规范，如git-config[1]的 "配置文件 "部分中的数值描述。 默认情况下，只有在启用日志输出时才会显示颜色（通过 color.diff, color.ui, 或 --color, 如果我们要去终端，要尊重前者的`auto`设置）。%C(auto,...)`被接受为默认的历史同义词（例如，%C(auto,red)）。指定%C(always,…)将显示颜色，即使没有启用颜色（尽管考虑使用--color=always`来启用整个输出的颜色，包括这个格式和其他任何git可能的颜色）。 auto`单独使用（即%C(auto)`）将在下一个占位符上开启自动着色，直到再次切换颜色。
左（<）、右（>）或边界（-）标记
%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> )，但两边都有填充（即文本居中）
显示 "G" 代表一个好的（有效的）签名，"B" 代表一个坏的签名，"U" 代表一个有效性未知的好的签名，"X" 代表一个已经过期的好的签名，"Y" 代表一个由过期的钥匙制作的好的签名，"R" 代表一个由撤销的 钥匙制作的好的签名，"E" 如果不能检查签名（如缺少钥匙），"N" 代表没有签名
显示已签名的提交的签名者的名字
显示用于签署已签名的承诺的密钥
显示用于签署已签名提交文件的密钥的指纹
显示主键的指纹，该主键的子键被用来签署一个已签署的提交
显示用于签署已签名的承诺的密钥的信任级别
reflog选择器，例如，refs/stash@{1}`或`refs/stash@{2分钟前}；其格式遵循`-g`选项的规则。@'前面的部分是命令行上给出的参考文献名称（所以`git log -g refs/heads/master`会产生`refs/heads/master@{0}）。
简化的 reflog 选择器；与 %gD 相同，但 refname 部分被缩短以利于人类阅读（因此 refs/heads/master 变成了 master）。
记录身份名称
引用日志身份名称（尊重 .mailmap，参见 git-shortlog[1] 或 git-blame[1]
重新记录身份邮件
引用日志身份电子邮箱（尊重 .mailmap，参见 git-shortlog[1] 或 git-blame[1]
%(trailers[:<选项>])
显示由 git-interpret-trailers[1] 解释的正文的为主。trailers 字符串后面可以有冒号和零个或多个逗号分隔的选项。 如果任何选项被多次提供，则最后出现的选项获胜。
key=<键>：只显示具有指定密钥的为主。匹配是不分大小写的，后面的冒号是可选的。如果多次给出选项，则显示与任何键匹配的为主行。该选项自动启用 only 选项，使拖车块中的非尾注行被隐藏。如果不希望这样，可以用 only=false 禁用。 例如，%(trailers:key=Reviewed-by) 显示键为 Reviewed-by 的拖车行。
only[=<布尔值>] ：选择是否应该包括来自尾注块的非尾注行。
separator=<sep>: specify the separator inserted between trailer lines. Defaults to a line feed character. The string <sep> may contain the literal formatting codes described above. To use comma as separator one must use %x2C as it would otherwise be parsed as next option. E.g., %(trailers:key=Ticket,separator=%x2C ) shows all trailer lines whose key is "Ticket" separated by a comma and a space.
unfold[=<布尔值>]：使它的行为就像 interpret-trailer 的 --unfold 选项被给出一样。例如，`%(trailers:only,unfold=true)`会展开并显示所有的尾注行。
keyonly[=<布尔值>]：只显示尾注的关键部分。
valueonly[=<布尔值>]：只显示尾注的值部分。
key_value_separator=<sep>: specify the separator inserted between the key and value of each trailer. Defaults to ": ". Otherwise it shares the same semantics as separator=<sep> above.
The boolean options accept an optional value [=<bool-value>]. The values taken by --type=bool git-config[1], like yes and off, are all accepted. Giving a boolean option without =<value> is equivalent to giving it with =true.
如果你在占位符的'%后面加了一个`+（加号），当且仅当占位符扩展为一个非空字符串时，在扩展前会立即插入换行符。
如果你在占位符的'%后面加了一个`-（减号），如果且仅当占位符扩展为空字符串时，紧接着扩展前的所有连续换行将被删除。
如果你在占位符的'%'后面加了一个``（空格），当且仅当占位符扩展到一个非空字符串时，空格就会紧接着插入扩展。
$ 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
使用 -p 选项运行 git-diff[1]、git-log[1]、git-show[1]、git-diff-index[1]、git-diff-tree[1] 或 git-diff-files[1] 会生成补丁文本。 你可以通过 GIT_EXTERNAL_DIFF 和 GIT_DIFF_OPTS 环境变量（参见 git[1]），以及 diff 属性（参见 gitattributes[5]）自定义补丁文本的创建。
What the -p option produces is slightly different from the traditional diff format:
File modes <mode> are printed as 6-digit octal numbers including the file type and file permission bits.
扩展头信息中的路径名称不包括 a/ 和 b/ 前缀。
相似性指数是未改变的行占比，而不相似性指数是改变的行占比。它是四舍五入的整数，后有百分号。因此，100%的相似度指数指为两个文件相等，而 100% 的不相似度意味着入新文件中没有旧文件中的行。
The index line includes the blob object names before and after the change. The <mode> is included if the file mode does not change; otherwise, separate lines indicate the old and the new mode.
含有 "不常见" 字符的路径名会被引用，这一点在配置变量` core.quotePath` 中有所解释（见 git-config[1]）。
输出中所有的 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
任何生成差异的命令都可以使用 -c 或 --cc 选项，在显示合并时产生一个 “合并差异”。当用 git-diff[1] 或 git-show[1] 显示合并时，这默认格式。还需要注意的是，你可以给这些命令适当的 --diff-merges 选项来强制生成特定格式的差异。
"合并的差异" 的格式如下：
diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
- static void describe(char *arg)
-static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
+ unsigned char sha1[20];
+ struct commit *cmit;
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
+ if (get_sha1(arg, sha1) < 0)
+ usage(describe_usage);
+ cmit = lookup_commit_reference(sha1);
+ if (!cmit)
+ usage(describe_usage);
if (!initialized) {
initialized = 1;
for_each_ref(get_name);
修改了文件块头信息的格式，以防止不小心将其送入 patch -p1。合并的差异格式是为审查合并提交的修改而创建的，并不是为了应用。这个变化类似于扩展的 "索引" 头信息的变化：
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
块中有（父提交数量+1）@ 字符，用于合并的差异格式。
与传统的 "统一" 差异格式不同，这种格式显示两个文件 A 和 B 的列，其中有 -（减号 — 在 A 中出现，但在 B 中删除），+（加号 — 在 A 中缺少，但在 B 中增加），或 " "（空格 — 不变）前缀，这种格式比较两个或多个文件与一个文件 X，并显示 X 与其中每个文件的差异。文件中的每一个都有一列被前置在输出行中，以指出 X 的行与它的不同之处。
第 N 列中的 - 字符意味着该行出现在文件 N 中，但它没有出现在结果文件中。第 N 列中的 + 字符意味着该行出现在结果文件中，而文件 N 中没有该行（换句话说，从该父提交的角度来看，该行是被添加的）。
在上面的输出示例中，两个文件中的函数签名都被改变了（因此从文件 1 和文件 2 中都有表示删除的 -，而 ++ 表示被添加的一行没有出现在文件 1 或文件 2 中）。另外还有 8 行与文件 1 中的相同，但没有出现在文件 2 中（因此前缀为 +）。
当用 git diff-tree -c 显示时，它将合并提交的父提交文件与合并结果进行比较（即文件 1 … 文件 N 是父提交文件）。当用 git diff-files -c 显示时，它将两个未解决的合并父提交文件与工作树文件进行比较（即文件 1 是阶段 2 ，又称 "我们的版本"，文件 2 是阶段 3，又称 "他们的版本"）。
显示自版本 v2.6.12 以来改变 include/scsi 或 drivers/scsi 子目录中任何文件的所有提交
git log --since="2 weeks ago" -- gitk
显示过去两周内对文件 gitk 的修改。 -- 是必要的，以避免与名为 gitk 的 分支 相混淆
git log --name-status release..test
显示在 "test "分支中但尚未在 "release "分支中的提交，以及每个提交修改的路径列表。
git log --follow builtin/rev-list.c
显示改变`builtin/rev-list.c`的提交，包括那些在文件被赋予现在名字之前发生的提交。
git log --branches --not --remotes=origin
显示所有在本地分支中但不在 "origin "的远程跟踪分支中的提交（你有而origin没有的东西）。
git log master --not --remotes=*/master
显示所有在本地主库但不在任何远程仓库主库分支中的提交。
git log -p -m --first-parent
显示包括变化差异的历史，但只从 "主分支 "的角度，跳过来自合并分支的提交，并显示合并带来的全部变化差异。 这只有在遵循严格的政策，在停留在一个集成分支时合并所有主题分支时才有意义。
git log -L /int main/',/^}/:main.c
显示了文件`main.c`中的函数`main()`是如何随时间演变的。
git log -3
将显示的提交数量限制在3个。
路径名以UTF-8规范化形式C编码，这适用于树对象、索引文件、参考名称，以及命令行参数、环境变量和配置文件（.git/config（见git-config[1]），gitignore[5]，gitattributes[5] 和gitmodules[5]）中的路径名。
请注意，Git 在核心层将路径名简单地视为非 NUL 字节的序列，没有路径名编码的转换（除了 Mac 和 Windows）。因此，即使在使用传统的扩展ASCII编码的平台和文件系统上，使用非ASCII的路径名大多也能工作。然而，在这种系统上创建的仓库在基于UTF-8的系统（如Linux、Mac、Windows）上将无法正常工作，反之亦然。 此外，许多基于Git的工具简单地认为路径名称是UTF-8，而不能正确显示其他编码。
提交日志信息通常以UTF-8编码，但也支持其他扩展ASCII编码。这包括ISO-8859-x、CP125x和其他许多编码，但不包括UTF-16/32、EBCDIC和CJK多字节编码（GBK、Shift-JIS、Big5、EUC-x、CP9xx等）。
git commit and git commit-tree issue a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to have i18n.commitEncoding in .git/config file, like this:
[i18n]
commitEncoding = ISO-8859-1
用上述设置创建的提交对象在它的 encoding 头中记录了 i18n.commitEncoding 的值。 这是为了帮助以后看这些对象的人。 缺少这个头意味着提交日志信息是以 UTF-8 编码的。
git log, git show, git blame and friends look at the encoding header of a commit object, and try to re-code the log message into UTF-8 unless otherwise specified. You can specify the desired output encoding with i18n.logOutputEncoding in .git/config file, like this:
[i18n]
logOutputEncoding = ISO-8859-1
如果你没有这个配置变量，则使用`i18n.commitEncoding`的值来代替。
