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

名称

git-shortlog - Summarize git log output

概述

git shortlog [<options>] [<revision range>] [[--] <path>…​] 。
git log --pretty=short | git shortlog [<options>] 。

描述

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

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

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

选项

-n
--numbered

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

-s
--summary

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

-e
--email

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

--format[=<format>]

代替提交主题，使用一些其他信息来描述每个提交。 <format>'可以是任何被’git log’的`--format’选项接受的字符串，比如'* [%h] %s'。 参见git-log[1]的 "PRETTY FORMATS "部分）。

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

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

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

  • 提交人"，提交内容按提交人分组（与 "c "相同）。

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

    请注意，不包括拖车的提交将不被计算在内。 同样地，有多个拖车的提交（例如多个签收）可以被计算一次（但该提交中每个独特的拖车值只能计算一次）。

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

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

-c
--committer

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

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

通过以`width`包裹每一行来对输出进行换行。 每个条目的第一行缩进`缩进1`个空格，第二行和后续行缩进`缩进2`个空格。width, indent1, 和`indent2`分别默认为76, 6和9。

如果宽度为`0`（零），则缩进输出的行数而不包裹它们。

<修订版范围>。

只显示指定修订范围内的提交。 当没有指定<修订范围>时，默认为`HEAD`（即导致当前提交的整个历史）。 origin...HEAD`指定了从当前提交（即`HEAD）可以到达的所有提交，但不是从`origin`。关于<revision range>的完整拼写方式，见gitrevisions[7]的 "指定范围 "部分。

[--] <路径>…​

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

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

承诺限制

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

使用更多的选项通常会进一步限制输出（例如，--since=<date1>`限制在比<date1>新的提交，与--grep=<pattern>一起使用会进一步限制在日志信息中有一行符合<pattern>`的提交），除非另有说明。

请注意，这些都是在提交排序和格式化选项之前应用的，如`--反转`。

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

限制输出的提交数量。

--skip=<number>

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

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

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

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

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

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

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

--grep-reflog=<pattern>

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

--grep=<pattern>

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

当`--笔记`生效时，笔记中的信息被匹配，就像它是日志信息的一部分。

--all-match

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

--invert-grep

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

-i
--regexp-ignore-case

匹配正则表达式的限制模式，不考虑字母大小写。

--basic-regexp

将限制性模式视为基本的正则表达式；这是默认的。

-E
--extended-regexp

将限制性模式视为扩展的正则表达式，而不是默认的基本正则表达式。

-F
--fixed-strings

将限制性模式视为固定字符串（不要将模式解释为正则表达式）。

-P
--perl-regexp

将限制性模式视为与Perl兼容的正则表达式。

对这些类型的正则表达式的支持是一个可选的编译时依赖。如果Git在编译时没有对它们的支持，提供这个选项将导致它死亡。

--remove-empty

当一个给定的路径从树上消失时停止。

--merges

只打印合并后的提交。这与`--min-parents=2`完全相同。

--no-merges

不打印有一个以上父级的提交。这与`--max-parents=1`完全相同。

--min-parents=<number>
--max-parents=<number>
--no-min-parents
--no-max-parents

只显示至少（或最多）有那么多父提交的提交。特别是，--max-parents=1`等同于--no-merges`，--min-parents=2`等同于--merges`。 --max-parents=0`给出所有根提交，--min-parents=3`给出所有章鱼合并。

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

在看到一个合并提交时，只关注第一个父提交。 在查看某个主题分支的演变时，这个选项可以提供一个更好的概览，因为合并到一个主题分支往往只是为了适应不时更新的上游，而这个选项可以让你忽略这种合并给你的历史带来的个别提交。

--not

颠倒"^"前缀（或没有前缀）对所有后续修订指定符的意义，直到下一个`--not`。

--all

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

--支部[=<模式>]

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

--tags[=<pattern>]

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

--remotes[=<pattern>]

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

--glob=<glob-pattern>

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

--exclude=<glob-pattern>（排除）。

不包括匹配"<glob-pattern>"的参考文献，否则下一个`--all`、--branches、--tags、--remotes`或--glob`会考虑这些参考文献。重复这个选项可以累积排除模式，直到下一个`----all`、---branches、---tags、---remotes`或---glob`选项（其他选项或参数不清除累积模式）。

当应用于"--分支"、"--标签 "或"--远程 "时，给出的模式不应该以 "refs/heads"、"refs/tags "或 "refs/remotes "开头，而当应用于"--glob "或 "all "时，必须以 "refs/"开头。如果打算使用尾部的"/*"，必须明确给出。

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

除了命令行上列出的'<commit>'之外，还要从标准输入中读取它们。如果看到`--`分隔符，就停止读取提交，开始读取路径以限制结果。

--cherry-mark

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

--cherry-pick

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

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

--left-only
--right-only

只列出对称性差异各自一侧的提交，即只列出那些通过"--左—​右 "标记的"<"或">"。

例如，--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`（由于明显的原因），这将导致输出有两行额外的信息来自reflog。 输出中的reflog代号可以显示为`ref@{Nth}（其中`Nth`是reflog中的逆序索引）或`ref@{timestamp}（带有该条目的时间戳），取决于一些规则。

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

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

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

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

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

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

--merge

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

--boundary

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

简化历史

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

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

<paths>

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

--simplify-by-decoration

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

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

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

Default mode

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

--show-pulls

包括默认模式下的所有提交，但也包括任何与第一个父分支不相干但与后来的父分支相干的合并提交。这种模式有助于显示 "首次引入 "某个分支的合并提交。

--full-history

与默认模式相同，但不修剪一些历史记录。

--dense

只显示所选的提交，再加上一些才有意义的历史。

--sparse

简化历史中的所有提交都会显示出来。

--simplify-merges

为`--full-history`增加了一个选项，可以从结果的历史中删除一些不必要的合并，因为没有选定的提交对这次合并有贡献。

--ancestry-path

当给定一个要显示的提交范围（例如 "commit1…​commit2 "或 "commit2 ^commit1"）时，只显示直接存在于 "commit1 "和 "commit2 "之间的祖先链的提交，即既是 "commit1 "的后代，又是 "commit2 "的祖先的提交。

以下是更详细的解释。

假设你指定了`foo`作为<paths>。 我们将把修改`foo`的提交称为 !TREESAME，其余的称为 TREESAME。 (在为`foo`过滤的diff中，它们看起来分别是不同的和相同的)。

在下文中，我们将始终引用同一个历史实例来说明简化设置之间的差异。 我们假设你在这个提交图中过滤的是一个文件`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`），包括或排除提交。以下设置是可用的。

Default mode

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

This results in:

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

请注意，如果有TREESAME父类的话，只遵循TREESAME父类的规则，将`B’完全排除在考虑之外。 `C`是通过`N`考虑的，但也是TREESAME。 根提交是与空树比较的，所以`I`是!!TREESAME。

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

--full-history without parent rewriting

这种模式与默认模式有一点不同：总是跟随一个合并的所有父本，即使它与其中一个父本是TREESAME。 即使合并的一方有多个提交被包括在内，这也不意味着合并本身也是如此在这个例子中，我们得到

	I  A  B  N  D  O  P  Q

‘M’被排除在外，因为它与父母都是TREESAME。 `E’、`C’和`B’都走了，但只有`B’是！"TREESAME"，所以其他的都没有出现。

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

--full-history with parent rewriting

普通的提交只有当它们是！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

将显示的提交限制在给定提交范围内 "from "和 "to "提交之间的直接祖先链上。也就是说，只显示 "to "提交的祖先和 "from "提交的后代的提交。

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

	    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

在讨论另一个选项，`--显示—​推力’之前，我们需要创建一个新的历史实例。

用户在查看简化历史时经常遇到的一个问题是，他们知道的对某个文件的修改提交并没有出现在该文件的简化历史中。让我们演示一个新的例子，并说明`--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`结果中。

当使用`--简化合并`选项时，提交的`O`和`P`从结果中消失。这是因为 "O "和 "P "重写的第二父本可以从它们的第一父本到达。这些边被移除，然后这些提交看起来就像与它们的父类一样的单亲提交。这也发生在提交`N`上，导致历史视图如下。

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

在这个视图中，我们看到了所有来自`A`，B`和`X`的重要单亲变化。我们还可以看到仔细解决的合并`M`和不那么仔细解决的合并`R。这些信息通常足以确定为什么`A`和`B`的提交在默认视图中从历史中 "消失 "了。然而，这种方法也有一些问题。

第一个问题是性能。与之前的任何选项不同，`--简化合并’选项需要在返回一个结果之前走完整个提交历史。这可能使该选项难以用于非常大的仓库。

第二个问题是审计的问题。当许多贡献者在同一个版本库中工作时，哪些合并提交将一个变化引入到一个重要的分支是很重要的。上面有问题的合并`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`的修改 "拉 "进了主分支。

`--按装饰简化’选项允许你只查看历史拓扑的全貌，省略那些没有被标签引用的提交。 如果(1)提交被标签引用，或者(2)提交改变了命令行上给出的路径内容，则被标记为！TREESAME（换句话说，按照上述历史简化规则保留）。 所有其他的提交都被标记为TREESAME（会被简化掉）。

制图作者

See gitmailmap[5].

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

GIT

Part of the git[1] suite

scroll-to-top