是否有一个包含merge（only）和non-merge提交的`git log`摘要？

Question

我不仅仅意味着git log，我知道它列出了所有内容。我正在寻找摘要。

我不确定这是否是最佳做法，但我使用git进行合并和壁球式提交。如果变化很小而且直截了当，我不明白它为什么需要合并提交，提交已经是原子的。另一方面，有时向代码添加逻辑函数包含多个原子步骤，在这种情况下我倾向于使用合并，以避免将多个步骤压缩在一起。

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

git log --merges似乎很接近，但它并没有列出压缩的提交，因此历史记录不完整。

[根据关于变基的评论进行编辑]我认为我的问题同时适用于git和github，但其中一条评论的问题让我意识到它并不完全正确。 Github允许你合并一个拉取请求或压缩它（它也允许重新设置提交，但我认为这是偏离主题的）。合并Pull请求会导致合并提交与pull请求中的提交集合，而Squash commit基本上与将提交提取到目标分支中相同（或者如果存在多个提交则压缩在PR）。

Answer 1

考虑到你使用Git的方式（我认为这是一种非常好的方式，但是StackOverflow上的意见令人不满:-)）你可以使用--first-parent选项得到你想要的东西。< / p>

详细说明

作为快速摘要提醒，当您使用git merge --squash（或＃34;通过壁球合并＆＃34;点击按钮github）时，Git最终做的是做一个普通提交，作为其内容，具有与真正合并相同的内容;但是这个新的普通提交只是一个普通的提交 - 只有一个父级，与要合并的提交无关。

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

* 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序列并不需要所有的＆＃34; oops＆＃34;和＆＃34;琐碎的修复＆＃34;要永久保存的东西，所以我们可以只做最后的提交：

* 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上相应的clicky按钮 - 相同的按钮，实际上，但设置为不同的模式）。

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

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

实际上有一种方法可以告诉git log（及其面向脚本的姐妹命令git rev-list）来做到这一点。 --first-parent标志告诉Git，当它遇到合并提交时，为了显示和图形行走的目的，它应该去除任何合并的第二个父。 ¹ 这留下其余的Git至少暂时处理这个提交，好像它是一个普通的非合并。这也是壁球合并的结果：由合并操作提交的提交，即Git的合并动词部分，但作为普通的单父提交添加到提交图中。

因此，git log --first-parent（也可选择-mp：请注意，出于修补目的，您通常希望-m避免组合差异行为）将获得您想要的内容。

¹ 一个包含两个以上父项的合并提交 - 称为章鱼合并 - 除了第一个之外的所有都被删除，因此选项姓名，＆＃34;第一个父母＆＃34;。大多数合并只有两个父母; GitHub本身无法进行章鱼合并。