识别'上游'合并提交，而不是从fork中识别

Question

我正在尝试在git历史记录中识别pull request merge commit。

我们通常可以使用类似的东西：

git log --merges |grep 'Merge pull request'`

但是，我是具有多个存储库分支的分布式项目的一部分，并且发现作为fork的开发流的一部分的pull请求合并提交正在污染此输出。这甚至可以在Github的用户界面中观察到。

示例：

18b389... Merge pull request #2222 from Fork/master  <-- Fork/master to Upstream/master for feature X -  Want.
ea3e5b... Merge pull request #12 from Fork/feature-x  <-- Fork/feature-x to Fork/master - Dont want.

我想只隔离叉子和上游之间的合并提交，而不是叉子叉子或叉子叉子之间。这可能吗？

我的实际目标是能够识别一系列提交之间的所有pull请求合并提交SHA，但是这些错误提交会通过引用不相关的PR来污染结果 - 提交消息中fork和upstream之间没有区别。

Answer 1

这不可能100％可靠地完成。但是有一些方法可以接近：

• 您可以在提交消息的其他部分grep吗？
• 你可以在Upstream的GitHub页面上浏览拉取请求列表吗？
• 尝试将--first-parent开关添加到您对git log的通话中。这可能不会给你所有相关的拉取请求，但它不应该给你任何你不想要的。

--first-parent告诉git log仅遵循合并提交的第一个父级，而不是跟随所有父级。合并的分支始终是第一个父级，因此这是查看直接在您正在查看的分支上发生的历史记录的有效方法。

可悲的是，有一件事可能会破坏第一个父母的历史，即有人拉动时发生的合并。如果Person A直接在master上工作，并且在此期间其他东西被推送到服务器，则当A拉动时将发生合并（除非另外配置）。在这种情况下，A的本地提交将是第一个父级，同时推送的任何内容将是第二个父级，这意味着它不会显示在git log --first-parent下。