Git
简体中文 ▾ Topics ▾ Latest version ▾ git-shortlog last updated in 2.43.2

名称

git-shortlog - 汇总 git log 输出

概述

git shortlog [<选项>] [<修订范围>] [[--] <路径>…​] 。
git log --pretty=short | git shortlog [<多个选项>] 。

描述

将’git log’输出总结为适合纳入发布公告的格式。每个提交将按作者和标题分组。

此外,"[PATCH]"将从提交描述中被剥离。

如果命令行上没有传递修订版,而且标准输入不是终端,或者没有当前分支,'git shortlog’将输出从标准输入读取的日志摘要,而不参考当前版本库。

选项

-n
--numbered

根据每个作者的提交数量对输出进行排序,而不是按照作者的字母顺序。

-s
--summary

抑制提交描述,只提供提交计数摘要。

-e
--email

显示每个作者的电子邮件地址。

--format[=<格式>]

Instead of the commit subject, use some other information to describe each commit. <format> can be any string accepted by the --format option of git log, such as * [%h] %s. (See the "PRETTY FORMATS" section of git-log[1].)

每个漂亮的印刷品承诺在展示之前都会被重新包装。
--date=<格式>

显示根据给定日期字符串格式化的日期。(参见git-log[1]中 "提交格式化"部分的`--date`选项)。与 `--group=format:<format>`一起使用会非常有用。

--group=<类型>

根据 <类型>`对提交进行分组。如果没有指定 `--group 选项,默认为 作者<类型> 是以下之一:

  • "作者",提交内容按作者分组

  • 提交者 ,提交内容按提交人分组(与 -c 相同)

  • trailer:<field><field>`被解释为不区分大小写的提交消息预告片(见 git-interpret-trailers[1])。例如,如果你的项目使用 `Reviewed-by 拖车,你可能想用 git shortlog -ns --group=trailer:reviewed-by 来查看谁在审核。

  • 格式:<format>`可以是任何被'git log'的--format’选项接受的字符串,比如'* [%h] %s'。 参见git-log[1]的 "PRETTY FORMATS "部分)。

    Note that commits that do not include the trailer will not be counted. Likewise, commits with multiple trailers (e.g., multiple signoffs) may be counted more than once (but only once per unique trailer value in that commit).

    Shortlog将尝试把每个拖车值解析为`name <email>的身份。如果成功,将应用mailmap,除非指定--email`选项,否则将省略email。如果该值不能被解析为一个身份,那么它将被完全视为字面意思。

如果"--组 "被多次指定,每个值下的提交都会被计算(但同样,每个提交中的唯一值只能计算一次)。例如,`git shortlog --group=author --group=trailer:co-authored-by`同时计算作者和共同作者。

-c
--committer

这是`--group=committer`的一个别名。

-w[<width>[,<indent1>[,<indent2>]]]

Linewrap the output by wrapping each line at width. The first line of each entry is indented by indent1 spaces, and the second and subsequent lines are indented by indent2 spaces. width, indent1, and indent2 default to 76, 6 and 9 respectively.

如果宽度为`0`(零),则缩进输出的行数而不包裹它们。

<revision-range>

Show only commits in the specified revision range. When no <revision-range> is specified, it defaults to HEAD (i.e. the whole history leading to the current commit). origin..HEAD specifies all the commits reachable from the current commit (i.e. HEAD), but not from origin. For a complete list of ways to spell <revision-range>, see the "Specifying Ranges" section of gitrevisions[7].

[--] <path>…​

只考虑那些足以解释符合指定路径的文件是如何产生的提交。

当出现混淆时,路径可能需要以`--`为前缀,以便将其与选项或修订范围分开。

承诺限制

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

Using more options generally further limits the output (e.g. --since=<date1> limits to commits newer than <date1>, and using it with --grep=<pattern> further limits to commits whose log message has a line that matches <pattern>), unless otherwise noted.

请注意,这些都是在提交排序和格式化选项之前应用的,如 --reverse

-<数>
-n <数量>
--max-count=<数量>

限制输出的提交数量。

--skip=<数量>

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

--since=<日期>
--after=<日期>

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

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

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

--until=<日期>
--before=<日期>

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

--author=<模式>
--committer=<模式>

Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression). With more than one --author=<pattern>, commits whose author matches any of the given patterns are chosen (similarly for multiple --committer=<pattern>).

--grep-reflog=<模式>

Limit the commits output to ones with reflog entries that match the specified pattern (regular expression). With more than one --grep-reflog, commits whose reflog message matches any of the given patterns are chosen. It is an error to use this option unless --walk-reflogs is in use.

--grep=<模式>

Limit the commits output to ones with a log message that matches the specified pattern (regular expression). With more than one --grep=<pattern>, commits whose message matches any of the given patterns are chosen (but see --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

Show only commits which have at least (or at most) that many parent commits. In particular, --max-parents=1 is the same as --no-merges, --min-parents=2 is the same as --merges. --max-parents=0 gives all root commits and --min-parents=3 all octopus merges.

--no-min-parents and --no-max-parents reset these limits (to no limit) again. Equivalent forms are --min-parents=0 (any commit has 0 or more parents) and --max-parents=-1 (negative numbers denote no upper limit).

--first-parent

When finding commits to include, follow only the first parent commit upon seeing a merge commit. This option can give a better overview when viewing the evolution of a particular topic branch, because merges into a topic branch tend to be only about adjusting to updated upstream from time to time, and this option allows you to ignore the individual commits brought in to your history by such a merge.

--exclude-first-parent-only

When finding commits to exclude (with a ^), follow only the first parent commit upon seeing a merge commit. This can be used to find the set of changes in a topic branch from the point where it diverged from the remote branch, given that arbitrary merges can be valid topic branch changes.

--not

Reverses the meaning of the ^ prefix (or lack thereof) for all following revision specifiers, up to the next --not. When used on the command line before --stdin, the revisions passed through stdin will not be affected by it. Conversely, when passed via standard input, the revisions passed on the command line will not be affected by it.

--all

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

--branches[=<模式>]

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

--tags[=<模式>]

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

--remotes[=<模式>]

Pretend as if all the refs in refs/remotes are listed on the command line as <commit>. If <pattern> is given, limit remote-tracking branches to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.

--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/headsrefs/tagsrefs/remotes 开头;当应用于 --glob--all 选项时,必须以 refs/ 开头。如果要使用尾部的 /*,则必须明确给出。

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

通过查阅相应的 fetch.hideRefsreceive.hideRefsuploadpack.hideRefs 配置和 transfer.hideRefs 配置(参见 git-config[1]),不要包含会被 git-fetchgit-receive-packgit-upload-pack 隐藏的引用。该选项会影响下一个伪引用选项 --all--glob,并在处理后清除。

--reflog

假设reflogs提到的所有对象都在命令行中被列为`<commit>`。

--alternate-refs

Pretend as if all objects mentioned as ref tips of alternate repositories were listed on the command line. An alternate repository is any repository whose object directory is specified in objects/info/alternates. The set of included objects may be modified by core.alternateRefsCommand, etc. See git-config[1].

--single-worktree

By default, all working trees will be examined by the following options when there are more than one (see git-worktree[1]): --all, --reflog and --indexed-objects. This option forces them to examine the current working tree only.

--ignore-missing

在看到输入中无效的对象名称时,假装没有给出坏的输入。

--bisect

假设坏的二分法参考文献`refs/bisect/bad`被列出,并且在命令行中假设它后面是`--not`和好的二分法参考文献`refs/bisect/good-*`。

--stdin

除从命令行获取参数外,还可从标准输入读取参数。它接受提交和伪选项,如 --all--glob=。当看到 -- 分隔符时,下面的输入将被视为路径并用于限制结果。通过标准输入读取的 --not 等标志只适用于以相同方式传递的参数,不会影响后续的命令行参数。

--cherry-mark

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

--cherry-pick

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

例如,如果你有两个分支,AB,通常的方法是用`--左—​右`列出其中一边的所有提交(见下面关于`--left-right`选项的描述)。然而,它显示的是从另一个分支中偷梁换柱的提交(例如,'3rd on b' 可能是从分支 A 中偷梁换柱的)。有了这个选项,这样的提交对将从输出中排除。

--left-only
--right-only

只列出对称性差异各自一侧的提交,即只列出那些通过 --left-right 标记的 <>

For example, --cherry-pick --right-only A...B omits those commits from B which are in A or are patch-equivalent to a commit in A. In other words, this lists the + commits from git cherry A B. More precisely, --cherry-pick --right-only --no-merges gives the exact list.

--cherry

--right-only --cherry-mark --no-merges`的同义词;有助于将输出限制在我们这边的提交,并标记那些已经应用到分叉历史的另一边的提交,`git log --cherry upstream...mybranch,类似于`git cherry upstream mybranch`。

-g
--walk-reflogs

Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones. When this option is used you cannot specify commits to exclude (that is, ^commit, commit1..commit2, and commit1...commit2 notations cannot be used).

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:

  1. 如果起点被指定为`ref@{Nth}`,显示索引格式。

  2. 如果起点被指定为`ref@{now}`,显示时间戳格式。

  3. 如果两者都没有使用,但在命令行中给出了`--date`,则按照`--date`所要求的格式显示时间戳。

  4. 否则,显示索引格式。

Under --pretty=oneline, the commit message is prefixed with this information on the same line. This option cannot be combined with --reverse. See also git-reflog[1].

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

--merge

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

--boundary

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

简化历史

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

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

<paths>

修改给定<路径>的提交会被选中。

--simplify-by-decoration

被某个分支或标签引用的提交被选中。

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

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

默认模式

将历史简化为解释树的最终状态的最简单的历史。最简单的原因是,如果最终结果相同,它会修剪一些侧枝(即合并具有相同内容的分支)

--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), 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.

以下是更详细的解释。

Suppose you specified foo as the <paths>. We shall call commits that modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for foo, they look different and equal, respectively.)

In the following, we will always refer to the same example history to illustrate the differences between simplification settings. We assume that you are filtering for a file foo in this commit graph:

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

The horizontal line of history A---Q is taken to be the first parent of each merge. The commits are:

  • ‘I`是初始提交,其中`foo`存在,内容是`asdf’,文件`quux`存在,内容是`quux'。初始提交与空树比较,所以`I`是!`TREESAME。

  • 在`A`中,‘foo`只包含`foo’'。

  • B contains the same change as A. Its merge M is trivial and hence TREESAME to all parents.

  • C`没有改变`foo,但是它的合并`N`将其改为`foobar'',所以它与任何父类都不存在TREESAME。

  • ‘D`将`foo`设置为`baz’。它的合并项`O`将`N`和`D`的字符串合并为`foobarbaz';也就是说,它与任何父类都不是TREESAME。

  • ‘E`将`quux`改为`xyzzy’,其合并的`P`将这些字符串合并为`quux xyzzy'。`P’与`O’的关系是TREESAME,但与`E’不是。

  • X`是一个独立的根提交,添加了一个新文件`sideY`修改了它。`Y`与`X`同为TREESAME。它的合并文件`Q`在`P`上添加了`side,`Q`与`P`是同源,但与`Y`不是同源。

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

默认模式

Commits are included if they are not TREESAME to any parent (though this can be changed, see --sparse below). If the commit was a merge, and it was TREESAME to one parent, follow only that parent. (Even if there are several TREESAME parents, follow only one of them.) Otherwise, follow all parents.

这将实现:

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

Note how the rule to only follow the TREESAME parent, if one is available, removed B from consideration entirely. C was considered via N, but is TREESAME. Root commits are compared to an empty tree, so I is !TREESAME.

父/子关系只有在使用 --parents 选项的情况下才能看到,但这并不影响在默认模式下选择的提交,所以我们显示了父行。

--full-history 无父级重写的完整历史记录

This mode differs from the default in one point: always follow all parents of a merge, even if it is TREESAME to one of them. Even if more than one side of the merge has commits that are included, this does not imply that the merge itself is! In the example, we get

	I  A  B  N  D  O  P  Q

M was excluded because it is TREESAME to both parents. E, C and B were all walked, but only B was !TREESAME, so the others do not appear.

请注意,如果没有父子重写,其实是不可能谈论提交之间的父子关系的,所以我们显示它们是不相连的。

--full-history 带父级重写功能的全历史记录

普通的提交只有当它们是!TREESAME时才会被包括在内(尽管这一点可以改变,见下面的`--sparse`)。

Merges are always included. However, their parent list is rewritten: Along each parent, prune away commits that are not included themselves. This results in

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

Compare to --full-history without rewriting above. Note that E was pruned away because it is TREESAME, but the parent list of P was rewritten to contain E's parent I. The same happened for C and N, and X, Y and Q.

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

--dense

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

--sparse

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

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

--simplify-merges

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

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

  • 将 "C "设为 "C"。

  • Replace each parent P of C' with its simplification P'. In the process, drop parents that are ancestors of other parents or that are root commits TREESAME to an empty tree, and remove duplicates, but take care to never drop all parents that we are TREESAME to.

  • If after this parent rewriting, C' is a root or merge commit (has zero or >1 parents), a boundary commit, or !TREESAME, it remains. Otherwise, it is replaced with its only parent.

The effect of this is best shown by way of comparing to --full-history with parent rewriting. The example turns into:

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

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

  • N's parent list had I removed, because it is an ancestor of the other parent M. Still, N remained because it is !TREESAME.

  • P's parent list similarly had I removed. P was then removed completely, because it had one parent and is 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`本身)。

When we want to find out what commits in M are contaminated with the bug introduced by D and need fixing, however, we might want to view only the subset of D..M that are actually descendants of D, i.e. excluding C and K. This is exactly what the --ancestry-path option does. Applied to the D..M range, it results in:

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

我们也可以用`--ancestry-path=D`来代替`--ancestry-path`,这在应用于’D…​M’范围时意思相同,只是更加明确。

If we instead are interested in a given topic within this range, and all commits affected by that topic, we may only want to view the subset of D..M which contain that topic in their ancestry path. So, using --ancestry-path=H D..M for example would result in:

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

For this example, suppose I created file.txt which was modified by A, B, and X in different ways. The single-parent commits C, Z, and Y do not change file.txt. The merge commit M was created by resolving the merge conflict to include both changes from A and B and hence is not TREESAME to either. The merge commit R, however, was created by ignoring the contents of file.txt at M and taking only the contents of file.txt at X. Hence, R is TREESAME to X but not M. Finally, the natural merge resolution to create N is to take the contents of file.txt at R, so N is TREESAME to R but not C. The merge commits O and P are TREESAME to their first parents, but not to their second parents, Z and Y respectively.

当使用默认模式时,`N’和`R`都有一个TREESAME父级,所以这些边被展示出来,其他边被忽略。由此产生的历史图是:

	I---X

当使用 --full-history 选项时,Git 会行走每条边。这将发现提交 AB 以及合并 M,但也将揭示合并提交 OP 。通过父级改写,得到的图是:

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

这里,合并提交 OP 带来了额外的输出,因为它们实际上并没有对 file.txt 做出改变。他们只是合并了一个基于 file.txt 旧版本的主题。这是在使用工作流程的仓库中常见的问题,在工作流程中,许多贡献者并行工作,并沿着一个主干合并他们的主题分支:不相关的合并出现在 --full-history 选项结果中。

当使用`--simplify-merges`选项时,提交的 OP 从结果中消失。这是因为 OP 重写的第二父本可以从它们的第一父本到达。这些边被移除,然后这些提交看起来就像与它们的父类一样的单亲提交。这也发生在提交 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`的修改 "拉 "进了主分支。

The --simplify-by-decoration option allows you to view only the big picture of the topology of the history, by omitting commits that are not referenced by tags. Commits are marked as !TREESAME (in other words, kept after history simplification rules described above) if (1) they are referenced by tags, or (2) they change the contents of the paths given on the command line. All other commits are marked as TREESAME (subject to be simplified away).

制图作者

参见 gitmailmap[5]

注意,如果`git shortlog`在版本库外运行(处理标准输入的日志内容),它将在当前目录下寻找一个`.mailmap`文件。

GIT

属于 git[1] 文档

scroll-to-top