是否有包含合并（仅）和非合并提交的“git log”摘要？

Question

我的意思不是简单的git log，我知道这列出了所有内容。我正在寻找摘要。

我不确定这是否是最佳实践，但我在 git 中同时使用了合并和压缩风格的提交。如果更改很小而且很直接，我不明白为什么它需要合并提交，提交已经是原子的。另一方面，有时向代码添加逻辑函数包含多个原子步骤，在这种情况下我倾向于使用合并，以避免将多个步骤压缩在一起。

我想知道是否有一种很好的方法可以在日志中总结这一点。也就是说，我可以只列出合并提交（当且仅当它是合并提交），否则列出非合并提交吗？这与编辑合并提交有关，因此它当然描述了正在添加的功能。

看起来git log --merges很接近，但它没有列出被压扁的提交，所以是一个不完整的历史。

[根据关于 rebase 的评论进行编辑] 我认为我的问题适用于 git 和 github，但其中一条评论中的问题让我意识到它并不完全正确。Github 允许您合并拉取请求或压缩它（它还允许重新提交提交，但我认为这是题外话）。合并拉取请求会导致合并提交与拉取请求中的一组提交，而 aSquash commit基本上与将提交挑选到目标分支中相同（如果 PR 中有多个提交，则压缩）。

Answer 1

鉴于您使用 Git 的方式（我认为这是一种非常好的方式，但在 StackOverflow 上的意见不赞成 :-) ）您可以使用该--first-parent选项获得您想要的东西。

详细描述

作为快速总结提醒，当您使用git merge --squash（或“通过壁球合并”点击按钮github），什么混帐做到底是为了使一个普通的提交有，作为它的内容，同样的内容，你会得到一个真正的合并; 但是这个新的普通提交只是——一个普通的提交——只有一个父级，与要合并的提交无关。

如果你要进行真正的合并，你会得到这个：

* a000000 (master) merge feature/tall
|\
| * ccccccc (feature/tall) fixing something trivial
| * bbbbbbb oops, forgot the cat
| * aaaaaaa take a stab at implementing "tall"
|/
* 9999999 some commit or another
* 8888888 the history goes on ...

等等。但是该功能的整个 A+B+C 序列不需要永久保存所有“糟糕”和“琐碎修复”的事情，因此我们可以改为进行最终提交：

* a000001 (master) implement the "tall" feature
|
| * ccccccc (feature/tall) fixing something trivial
| * bbbbbbb oops, forgot the cat
| * aaaaaaa take a stab at implementing "tall"
|/
* 9999999 some commit or another
* 8888888 the history goes on ...

然后feature/tall完全扔掉。然后我们得到一个很好的序列，其中整个特征一次出现。

但是，正如您在问题中所说，有时分步引入功能更有意义：

* f000000 (master) merge feature/short
|\
| * eeeeeee (feature/short) use the new facility to implement feature
| * ddddddd replace specific hack with new generic facility
| * bcdefed clean up an earlier specific hack
|/
* a000001 implement the "tall" feature
* 9999999 some commit or another
* 8888888 the history goes on ...

我们可以通过--no-ff合并（或 GitHub 上相应的点击按钮——实际上是同一个按钮，但设置为不同的模式）来做到这一点。

和以前一样，我们可以feature/short完全删除标签，因为它现在已经完成了（好吧，据我们所知已经完成，也许将来需要修复错误，但那是那时，而不是现在）。

查看此历史记录时，假设我们可以告诉 Git：请仅查看历史记录左侧的提交。 然后我们会看到引入的单个提交feature/tall（即使名称不见了），因为它是a000001; 但在此之前，我们还会看到，作为单个提交，就好像它是通过压缩（只是它不是，如果我们想要的话，完整的细节仍然在存储库中）带来的合并提交feature/short.

事实上，有一种方法可以告诉git log（及其面向脚本的姊妹命令git rev-list）这样做。该--first-parent标志告诉 Git，当它遇到合并提交时，出于显示和图形遍历的目的，它应该删除任何合并的第二个父项。¹ 这让 Git 的其余部分至少在目前处理这个提交，就好像它是一个普通的非合并。这也是壁球合并：由合并操作（Git 的合并作为动词部分）进行的提交，但作为普通的单父提交添加到提交图中。

因此，git log --first-parent（也可以选择使用-mp：请注意，出于补丁目的，您通常希望-m避免组合差异行为）将在这里得到您想要的。

¹具有两个以上父级的合并提交（称为章鱼合并）将除去除第一个之外的所有内容，因此选项名称为“第一个父级”。不过，大多数合并只有两个父级；GitHub 本身无法进行八达通合并。