Question

我想在去年列出合并提交。所以我用这个：

git log --reverse --since=2016-01-01 --until=2016-12-31 --merges

然而，这带来了大量的合并，我想只列出那些在主分支中合并多于提交的合并。

存储库中使用的流程为the GitHub Flow。

理想情况下，我希望能够列出已合并至少N次提交的合并。

Answer 1

这需要定义“合并 N 提交”意味着什么，因为有两个明显的定义，我认为第一个明显的定义是错误的，但我不确定第二个明显的是正确的。

首先，让我们注意合并提交 - 这些是由--merges选择的 - 是任何提交两个或更多父母。这是合并的名词形式，如gitglossary中所定义。

由于很容易计算父项的数量，我们可以将“合并 N 提交的合并”定义为“至少包含 N 的合并 - 1个父项”。然后，所有合并将合并至少1个提交，而合并2个提交的合并将具有3个父级。请注意，3或更多父组合也称为章鱼合并。例如，找到这些：git rev-list --min-parents=3 <starting-point>是微不足道的。将--merges与git log或git rev-list一起使用 - 这些命令大致相同，默认输出略有不同 - 只是--min-parents=2的简写，即只选择合并的提交提交。

大概是不是你的意思。这让我们得到了另一个明显的定义，但它更不那么明显了。

与往常一样，我们需要从绘制提交图的位开始。在您运行git merge的典型情况下，您会遇到以下情况：

...--o--*--o--o--o      <-- main
         \
          o--o----o     <-- feature

您现在git checkout main然后git merge feature，如果一切顺利且Git可以自行合并，您会得到：

...--o--*--o--o--o--M   <-- main
         \         /
          o--o----o     <-- feature

在这种情况下，合并的提交数量为三：feature上有三个提交不在main上。（有许多提交 - 从*开始向左工作，每次提交都会一直回到第一次提交，可能是之前两个分支。现在，三次提交仅在feature上的那些也在两个分支上。）

但这张图非常简单。这是一个不是很复杂的，但也不是那么简单：

...--o--*--o   <-- main
         \
          \      o   <-- fix1
           \    / \
            o--o   o--o   <-- feature
                \ /
                 o   <-- fix2

不明显有多少提交需要计算。 feature上有六个提交不在main上，但是其中两个提交的分支名称（fix1和fix2）直接指向它们，所以只有两个提交仅在feature上提交，三个提交在feature和fix1上提交，三个提交 - 两个相同，一个不同 - 与{共享{1}}。我们算所有六个吗？我们算五个吗？我们只计算两个吗？

在足够复杂的图中，可能存在多个合并基础。在这种情况下，fix2默认执行递归合并（默认的git merge策略是-s），它通过合并合并基础提交来工作，相当于临时提交结果，然后使用该临时提交合并为合并基础。这是最难解决的问题，因为不清楚是否将虚拟合并库计为提交。

假设以上所有都有意义，这里是如何计算

我们获得了现有的合并提交 M ，并要求计算它“引入”的提交数量。计算它们的最简单，最简单的方法 - 可能是你想要的计数，但考虑以上所有 - 也是计算从2到 P -th父级（ P -parent commit M ），不计算通过第一个父级可以访问的提交：

recursive

这使用gitrevisions syntax来选择提交git rev-list --count M^@ ^M^1的所有父级：

其他M父母速记符号
   存在另外两个简写，对于合并提交特别有用    命名由提交形成的集合及其父提交。

<rev>^符号表示r1^@的所有父母。 [剪断]

因此，我们要求r1找到所有父级可以访问的所有提交，不包括从第一个父级可以访问的所有提交。（没有必要从第一个参数中排除第二个，即git rev-list集合，因为排除第二个集合可以处理它。）这是有效的，因为M^1，M^1的第一个父节点。 {1}}，始终是您运行M之前在分支上的提交。因此，通过父母2到 P 引入的提交以及当时尚未在分支机构中的所有祖先都会被计算在内。

（对于我的第一个图表，计数将是3，而对于我的第二个图表，它将是6.如果这些不您需要的计数，则必须优化您的问题。）

将此git merge步骤放在您从git rev-list --count获取的提交ID上运行的脚本中，并选择结果计数至少为您选择的限制的脚本。将最终的提交哈希列表提供给git rev-list --merges --since ... --until ...以查看它们。

Git日志合并提交合并超过1次提交

1 个答案:

假设以上所有都有意义，这里是如何计算