git - 是否有包含 merge (仅)和非 merge 提交的 `git log` 摘要？

Question

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

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

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

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

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

Answer 1

考虑到您使用 Git 的方式(我认为这是一种非常好的方式，但在 StackOverflow 上的意见不受欢迎:-))您可以使用 --first-parent 获得您想要的东西选项。

详细描述

作为快速总结提醒，当您使用 git merge --squash 时(或 github 上的“通过 Squash merge ”单击按钮)，Git 最后所做的是进行普通提交，其内容与真正 merge 时获得的内容相同；但是这个新的普通提交只是——一个普通的提交——只有一个父级，与要 merge 的提交无关。

如果你要进行真正的 merge ，你会得到这个:

* 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 做到这一点 merge (或 GitHub 上相应的点击按钮——实际上是同一个按钮，但设置为不同的模式)。

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

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

其实有办法告诉git log (及其面向脚本的姊妹命令 git rev-list )来做到这一点。 --first-parent flag 告诉 Git，当它遇到 merge 提交时，为了显示和图形遍历的目的，它应该去掉任何 merge 的第二个父项。 1 这让 Git 的其余部分至少在目前处理这个提交，好像这是一个普通的非 merge 。这也是 Squash merge :由 merge 操作(Git 的 merge 作为动词部分)进行的提交，但作为普通的单父提交添加到提交图中。

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

1具有两个以上父级的 merge 提交(称为 Octopus merge )将被剥离除第一个之外的所有内容，因此选项名称为“第一个父级”。不过，大多数 merge 只有两个父级； GitHub 本身无法进行八爪鱼 merge 。