Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.51.2 no changes
-
2.51.1
2025-10-15
-
2.51.0
2025-08-18
- 2.50.1 no changes
-
2.50.0
2025-06-16
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 no changes
-
2.48.0
2025-01-10
- 2.46.1 → 2.47.3 no changes
-
2.46.0
2024-07-29
- 2.45.4 no changes
-
2.45.3
2024-11-26
- 2.45.1 → 2.45.2 no changes
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.4 no changes
-
2.44.0
2024-02-23
- 2.43.3 → 2.43.7 no changes
-
2.43.2
2024-02-13
- 2.43.1 no changes
-
2.43.0
2023-11-20
- 2.42.2 → 2.42.4 no changes
-
2.42.1
2023-11-02
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 no changes
-
2.41.0
2023-06-01
- 2.40.1 → 2.40.4 no changes
-
2.40.0
2023-03-12
- 2.39.1 → 2.39.5 no changes
-
2.39.0
2022-12-12
- 2.38.3 → 2.38.5 no changes
-
2.38.2
2022-12-11
- 2.38.1 no changes
-
2.38.0
2022-10-02
- 2.37.1 → 2.37.7 no changes
-
2.37.0
2022-06-27
- 2.36.1 → 2.36.6 no changes
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 no changes
-
2.35.0
2022-01-24
- 2.33.3 → 2.34.8 no changes
-
2.33.2
2022-03-23
-
2.33.1
2021-10-12
-
2.33.0
2021-08-16
- 2.32.1 → 2.32.7 no changes
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 no changes
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 no changes
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.28.1 no changes
-
2.28.0
2020-07-27
- 2.27.1 no changes
-
2.27.0
2020-06-01
- 2.26.1 → 2.26.3 no changes
-
2.26.0
2020-03-22
- 2.25.2 → 2.25.5 no changes
-
2.25.1
2020-02-17
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 no changes
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 no changes
-
2.23.0
2019-08-16
- 2.22.1 → 2.22.5 no changes
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 no changes
-
2.20.0
2018-12-09
- 2.19.3 → 2.19.6 no changes
-
2.19.2
2018-11-21
- 2.19.1 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.17.1 → 2.17.6 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
-
2.3.10
2015-09-28
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
描述
显示提交日志。
列出可以从给定的提交中通过 "父 "链接到达的提交,但不包括可以从前面有"^"的提交中到达的提交。 默认情况下,输出结果是按时间顺序倒置的。
你可以把它看成是一个集合操作。从命令行上给出的任何一个提交中可以到达的提交形成一个集合,然后从这个集合中减去任何一个前面带有'^'的提交。 剩下的提交内容就是命令的输出结果。 其他各种选项和路径参数也可以用来进一步限制结果。
因此,可以执行以下命令:
$ git log foo bar ^baz
意思是 "列出所有可以从’foo’或’bar',但不能从’baz’到达的提交"。
A special notation "<commit1>..<commit2>" can be used as a short-hand for "^<commit1> <commit2>". For example, either of the following may be used interchangeably:
$ git log origin..HEAD $ git log HEAD ^origin
Another special notation is "<commit1>...<commit2>" which is useful for merges. The resulting set of commits is the symmetric difference between the two operands. The following two commands are equivalent:
$ 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",则不会打印引用名称的前缀 "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
-
如果不使用此标志,
gitlog-p<path>... 将显示与指定路径相关的提交,并显示关于相同指定路径的差异。使用此标志,将显示与指定路径相关的提交的完整差异;这意味着 "<path>…" 将仅限定提交,并不限定这些提交的差异。请注意,这会影响所有基于差异的输出类型。例如:由
--stat等产生的输出。 - --log-size
-
在每个提交的输出中包含一行 ``log size <number>"" ,其中 <number> 是该提交消息的字节长度。旨在通过允许工具预先分配空间,加快从
gitlog输出中读取日志消息的工具的速度。 - -L<起始>,<结束>:<文件>
- -L :<函数名称>:<文件>
-
追踪由 <起始>,<结束> 给出的行的范围,或由函数名称重合词 <函数名称> 给出的行的演变,在 <文件>'中 。你不能给出任何路径规范限制条件。 目前这只限于从一个修订版开始的行走,也就是说,你只能给出零或一个正的修订版参数,而且 '<起始> 和 <结束>(或 <函数名称>)必须存在于起始修订版中。 你可以多次指定这个选项。包含
--patch选项。 补丁输出可以用--no-patch来抑制,但其他差异格式(即--raw、--numstat、--shortstat、--dirstat、--summary、--name-only、--name-status、--check)目前没有实现。<开始> 和 <结束> 可以采取这些形式之一:
-
数目
如果'<开始>'或'<结束>'是一个数字,它指定了一个绝对行数(行数从1开始计算)。
-
/正则表达式/
这种形式将使用与给定的 POSIX 正则表达式匹配的第一行。如果 <start> 是一个重词,它将从前一个
-L范围的末尾开始搜索,如果有的话,则从文件的开始。 如果 <start> 是^/regex/,它将从文件的开始搜索。 如果 <end> 是一个正则表达式,它将从 <start> 所给的行开始搜索。 -
+offset或-offset
这只对'<end>'有效,将指定'<start>'所给的行前或行后的数量。
如果
:<funcname> 代替了 <start> 和 <end> ,它是一个正则表达式,表示从第一个匹配 <funcname> 的 funcname 行开始,直到下一个 funcname 行的范围。:<funcname> 从上一个-L范围的末尾开始搜索,如果有的话,则从文件的开始搜索。^:<funcname>`从文件的开始搜索。函数名的确定方式与 `git diff 确定补丁组头的方式相同(见 gitattributes[5] 中的’定义自定义组头')。 -
- <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=<模式>`指定的模式不匹配。
- -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
-
查找要包含的提交时,在看到合并提交时只跟随第一个父提交。 在查看某个特性分支的演变时,该选项可以提供更好的概览,因为合并到特性分支往往只是为了不时地适应上游的更新,而该选项可以让你忽略由合并带来的历史中的单个提交。
这个选项也改变了合并提交的默认差异格式为
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/开头。如果要使用尾部的 /*,则必须明确给出。 -
通过查阅相应的
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`。
- -g
- --walk-reflogs
-
不走提交祖先链,而走从最近的提交到更早的提交的reflog条目。 使用这个选项时,你不能指定要排除的提交(也就是说,不能使用'^commit'、'commit1…commit2’和’commit1/…commit2’的符号)。
With
--prettyformat other thanonelineandreference(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 asref@{<Nth>}(where <Nth> is the reverse-chronological index in the reflog) or asref@{<timestamp>}(with the <timestamp> for that entry), depending on a few rules:-
If the starting point is specified as
ref@{<Nth>}, show the index format. -
如果起点被指定为`ref@{now}`,显示时间戳格式。
-
如果两者都没有使用,但在命令行中给出了`--date`,则按照`--date`所要求的格式显示时间戳。
-
否则,显示索引格式。
在`--pretty=oneline`下,提交信息的前缀是同一行中的这些信息。 这个选项不能与 `--reverse`结合使用。 参见 git-reflog[1]。
在`--pretty=reference`下,这些信息将完全不显示。
-
- --merge
-
显示在范围
HEAD...<其他> 中触及冲突路径的提交,其中 <其他> 是MERGE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD或REBASE_HEAD中第一个存在的伪引用。仅在索引中有未合并条目时有效。这个选项可以在解决三向合并中的冲突时用来显示相关的提交。 - --boundary
-
输出排除的边界提交。边界提交的前缀是"-"。
简化历史
有时你只对历史的一部分感兴趣,例如修改某个<路径>的提交。但 "历史简化 "有两部分,一部分是选择提交,另一部分是如何做,因为有各种策略来简化历史。
以下选项选择要显示的提交:
请注意,可以显示额外的提交,以提供一个有意义的历史。
以下选项会影响简化的执行方式:
- 默认模式
-
将历史简化为解释树的最终状态的最简单的历史。最简单的原因是,如果最终结果相同,它会修剪一些侧枝(即合并具有相同内容的分支)
- --show-pulls
-
包括默认模式下的所有提交,但也包括任何与第一个父分支不相干但与后来的父分支相干的合并提交。这种模式有助于显示 "首次引入 "某个分支的合并提交。
- --full-history
-
与默认模式相同,但不修剪一些历史记录。
- --dense
-
只显示所选的提交,再加上一些才有意义的历史。
- --sparse
-
简化历史中的所有提交都会显示出来。
- --simplify-merges
-
为`--full-history`增加了一个选项,可以从结果的历史中删除一些不必要的合并,因为没有选定的提交对这次合并有贡献。
- --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 的横线被认为是每次合并的第一个父本。 这些提交是:
-
‘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 \ 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 `的修改,因此与其中任何一个都不是同源的。然而,合并提交`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(会被简化掉)。
承诺订购
默认情况下,提交的内容是按时间顺序倒序显示的。
- --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`结合使用。
承诺格式化
- --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个空格(即 "中",这是默认的,"全",和 "更全")。
- --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来检查已签名的提交对象的有效性,并显示输出。
- --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。
-
- --parents
-
也可以打印提交的父类(以 "提交父类… "的形式)。 也可以启用父级改写,见上面的 "历史简化"。
- --children
-
同时打印提交的子项(以 "提交子项… "的形式)。 也可以启用父级改写,见上面的 "历史简化"。
- --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>",就会显示这个字符串,而不是默认的。
漂亮的格式
如果提交是一个合并,并且如果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>。
占位符是:
-
占位符,可扩展为一个字面字符:
-
影响后面占位符的格式化的占位符:
- %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
-
在命令行中给出的提交名称(如
gitlog--source),只对gitlog起作用 - %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分钟前};其格式遵循`-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=<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
%x2Cas 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.
-
-
|
Note
|
一些占位符可能取决于给修订版遍历引擎的其他选项。例如,%g* reflog选项将插入一个空字符串,除非我们正在遍历reflog条目(例如,通过`git log -g`)。%d`和%D`占位符将使用 "短 "装饰格式,如果`--decorate`没有在命令行上提供。
|
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.
如果你在占位符的'%后面加了一个`+(加号),当且仅当占位符扩展为一个非空字符串时,在扩展前会立即插入换行符。
如果你在占位符的'%后面加了一个`-(减号),如果且仅当占位符扩展为空字符串时,紧接着扩展前的所有连续换行将被删除。
如果你在占位符的'%'后面加了一个``(空格),当且仅当占位符扩展到一个非空字符串时,空格就会紧接着插入扩展。
-
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 log`不会产生任何差异输出。下面的选项可以用来显示每次提交所做的修改。
请注意,除非明确给出了 --diff-merges 变体(包括短 -m、-c、--cc 和 --dd 选项),否则合并提交不会显示差异,即使选择了 --patch 等差异格式,也不会匹配 -S 等搜索选项。使用 --first-parent 时例外,在这种情况下,--first-parent 是合并提交的默认格式。
|
Warning
|
Missing See original version for this content. |
使用选项 -p 生成补丁文本
使用 -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:
-
它前面有一个
gitdiff头,如下所示:diff --git a/file1 b/file2
a/和b/的文件名相同,除非涉及到重命名/复制。特别地,即使是创建或删除,也 不 使用/dev/null来代替a/或b/文件名。当涉及重命名/复制时,
file1和file2分别显示重命名/复制的源文件名和重命名/复制产生的文件名。 -
它的后面是一个或多个扩展头信息行:
oldmode<mode>newmode<mode>deletedfilemode<mode>newfilemode<mode>copyfrom<path>copyto<path>renamefrom<path>renameto<path>similarityindex<number>dissimilarityindex<number>index<hash>..<hash> <mode>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
-
块头提到了块头所适用的函数的名称。 参见 gitattributes[5] 中的 “定义自定义 hunk-header”,以了解如何针对特定语言进行定制。
合并的差异格式
任何生成差异的命令都可以使用 -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);
-
它前面有 "git diff" 头,如下(当使用
-c选项时):diff --combined file
或如下(当使用
--cc选项时):diff --cc file
-
它的后面是一个或多个扩展头信息行(本例显示的是与两个父提交的合并):
index<hash>,<hash>..<hash>mode<mode>,<mode>..<mode>newfilemode<mode>deletedfilemode<mode>,<mode>The
mode<mode>,<mode>..<mode> line appears only if at least one of the <mode> is different from the rest. Extended headers with information about detected content movement (renames and copying detection) are designed to work with the diff of two <tree-ish> and are not used by combined diff format. -
它的后面是两行源文件/目标文件的头信息:
--- a/file +++ b/file
与传统 ‘统一’ diff 格式的双行标题类似,
/dev/null用于表示已创建或已删除的文件。但是,如果提供了 --combined-all-paths 选项,你就会得到一个 N+1 行的源文件/目标文件头,其中 N 是合并提交中的父提交数量:
--- a/file --- a/file --- a/file +++ b/file
如果重命名或复制检测处于活动状态,这种扩展格式可能很有用,可以让你在不同的父提交中看到文件的原始名称。
-
修改了文件块头信息的格式,以防止不小心将其送入
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,又称 "他们的版本")。
实例
-
gitlog--no-merges -
显示整个提交历史,但跳过任何合并内容
-
gitlogv2.6.12..include/scsidrivers/scsi -
显示自版本 v2.6.12 以来改变
include/scsi或drivers/scsi子目录中任何文件的所有提交 -
gitlog--since="2weeksago"--gitk -
显示过去两周内对文件 gitk 的修改。
--是必要的,以避免与名为 gitk 的 分支 相混淆 -
gitlog--name-statusrelease..test -
显示在 "test "分支中但尚未在 "release "分支中的提交,以及每个提交修改的路径列表。
-
gitlog--followbuiltin/rev-list.c -
显示改变`builtin/rev-list.c`的提交,包括那些在文件被赋予现在名字之前发生的提交。
-
gitlog--branches--not--remotes=origin -
显示所有在本地分支中但不在 "origin "的远程跟踪分支中的提交(你有而origin没有的东西)。
-
gitlogmaster--not--remotes=*/master -
显示所有在本地主库但不在任何远程仓库主库分支中的提交。
-
gitlog-p-m--first-parent -
显示包括变化差异的历史,但只从 "主分支 "的角度,跳过来自合并分支的提交,并显示合并带来的全部变化差异。 这只有在遵循严格的政策,在停留在一个集成分支时合并所有主题分支时才有意义。
-
gitlog-L/intmain/',/^}/:main.c -
显示了文件`main.c`中的函数`main()`是如何随时间演变的。
-
gitlog-3 -
将显示的提交数量限制在3个。
讨论
Git在某种程度上是与字符编码无关的。
-
blob对象的内容是未经解释的字节序列。 在核心层没有编码转换。
-
路径名以UTF-8规范化形式C编码,这适用于树对象、索引文件、参考名称,以及命令行参数、环境变量和配置文件(
.git/config(见git-config[1]),gitignore[5],gitattributes[5] 和gitmodules[5])中的路径名。请注意,Git 在核心层将路径名简单地视为非 NUL 字节的序列,没有路径名编码的转换(除了 Mac 和 Windows)。因此,即使在使用传统的扩展ASCII编码的平台和文件系统上,使用非ASCII的路径名大多也能工作。然而,在这种系统上创建的仓库在基于UTF-8的系统(如Linux、Mac、Windows)上将无法正常工作,反之亦然。 此外,许多基于Git的工具简单地认为路径名称是UTF-8,而不能正确显示其他编码。
-
提交日志信息通常以UTF-8编码,但也支持其他扩展ASCII编码。这包括ISO-8859-x、CP125x和其他许多编码,但不包括UTF-16/32、EBCDIC和CJK多字节编码(GBK、Shift-JIS、Big5、EUC-x、CP9xx等)。
尽管我们鼓励提交日志信息使用UTF-8编码,但核心系统和Git Porcelain的设计并不强制要求项目使用UTF-8。 如果某个项目的所有参与者都认为使用传统编码更方便,Git也不会禁止。 然而,有几件事需要注意。
-
gitcommitandgitcommit-treeissue 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 havei18n.commitEncodingin.git/configfile, like this:[i18n] commitEncoding = ISO-8859-1
用上述设置创建的提交对象在它的
encoding头中记录了i18n.commitEncoding的值。 这是为了帮助以后看这些对象的人。 缺少这个头意味着提交日志信息是以 UTF-8 编码的。 -
gitlog,gitshow,gitblameand friends look at theencodingheader 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 withi18n.logOutputEncodingin.git/configfile, like this:[i18n] logOutputEncoding = ISO-8859-1
如果你没有这个配置变量,则使用`i18n.commitEncoding`的值来代替。
请注意,我们特意选择在提交对象层面上,不对提交日志信息进行重新编码,因为重新编码为UTF-8不一定是一个可逆的操作。
配置
核心变量见 git-config[1] ,与 diff 生成相关的设置见 git-diff[1] 。
本节中这一行以上的内容并不包括在 git-config[1] 文档中。下面的内容与那里的内容相同:
|
Warning
|
Missing See original version for this content. |
|
Warning
|
Missing See original version for this content. |
GIT
属于 git[1] 文档