是否有可能从Github网站或API获取合并列表到分支？

Question

在我们的工作流程中,没有"直接"提交进入主分支.主分支仅接收来自Pull请求的合并.

我们可以将每个合并视为添加到主分支的新功能.

所以我想得到一个合并到master的列表,作为一种可视化随着时间的推移添加到产品中的功能块的方法.

git或Github API是否公开了这个查询,还是我必须解析原始提交？

Answer 1

我使用以下脚本:

git log --merges --first-parent master \
        --pretty=format:"%h %<(10,trunc)%aN %C(white)%<(15)%ar%Creset %C(red bold)%<(15)%D%Creset %s"

解释每个论点:

• --merges:只有"合并"提交(超过1个父级);
• --first-parent master:仅应用合并master.这将删除某人合并master到其分支中的条目;
• --pretty-format:应用以下格式:
  • %h:提交短哈希;
  • %<(10,trunc)%aN:作者姓名,截断为10个字符;
  • %<(15)%ar:相对提交时间,填充到15个字符;
  • %<(15)%D:标签名称,也填充到15个字符;
  • %s:提交消息的第一行.

结果非常令人满意:

Answer 2

Git通过git log命令公开了这样的功能.此命令接受一些根据父提交的数量过滤呈现的提交的开关.

其中一个符合您的要求:

• --merges仅打印合并提交.这完全一样--min-parents=2.

以下显示了可从LibGit2Sharp项目的vNext分支到达的合并提交(即,具有多个父项的提交)

$ git log vNext --merges --oneline
090b2de Merge pull request #348 from jamill/credential_callback_fix
0332c35 Merge pull request #260 from ben/great-renaming
3191c1b Merge pull request #239 from ben/libgit2-upgrade-81eecc3
1d544e8 Merge branch 'vNext'
238d259 Merge remote-tracking branch 'origin/master'

更新

通过GitHub API获得相同的输出是可能的,但会更复杂一些.

这将需要从分支中检索所有提交,对所有结果进行分页(以便检索所有提交元数据),同时过滤掉仅显示一个父节点的提交.

作为起点,以下网址显示了该vNext分支的最新30个提交.

• https://api.github.com/repos/libgit2/libgit2sharp/commits?sha=vNext

Answer 3

如果您想专注于合并拉取请求的结果的合并提交，您可以考虑新的 Git 2.27（2020 年第二季度）git log --show-pulls选项。

“ git log”已经学会了“ --show-pulls”，这有助于路径规范限制历史视图；除了引入实际更改的提交之外，还显示了从侧分支获取整个更改的合并提交（通常从输出中省略）。

请参阅Derrick Stolee ( )提交的 8d049e1（2020 年 4 月 10 日）。^{（由Junio C Hamano合并-- --在提交 9af3a7c 中，2020 年 4 月 22 日）}derrickstolee
gitster

revision: --show-pulls 添加有用的合并

^{签字人：德里克·斯托利}

" git log -- <path>" 或 " git rev-list -- <path>"的默认文件历史简化侧重于提供首先贡献更改的最小提交集。
当一个合并提交存在时，修订遍历通过仅访问合并提交的第一个 TREESAME 父项来极大地限制遍历提交的集合。这意味着提交图的部分不会被遍历，这可能是一个性能优势，但也可以“隐藏”添加更改但被合并解决方案忽略的提交。

（TREESAME：各个树之间的路径规格没有明显差异；“树之间相同”）

该--full-history选项通过遍历所有提交并将合并提交报告为“有趣”来修改它，如果它有任何不是 TREESAME 的父提交。
这往往是对重要提交的过度表示，尤其是在大多数合并提交是通过拉取请求完成创建的环境中。

假设我们有一个提交，A并且我们B在顶部创建了一个提交来更改我们的文件。
当我们合并拉取请求时，我们创建了一个合并提交M。
如果没有其他人在M和之间更改第一父历史记录中的文件A，则不M会将 TREESAME 变为其第一个父，而是将 TREESAME 变为B。因此，简化的历史将是“ B”。但是，M 将出现在--full-history模式中。

但是，假设有许多主题T1, T2, ...,Tn是基于 commits C1, C2, ..., Cnbetween Aand之间创建的，M如下所示：

A----C1----C2--- ... ---Cn----M------P1---P2--- ... ---Pn
 \     \     \            \  /      /    /            /
  \     \__.. \            \/ ..__T1    /           Tn
   \           \__..       /\     ..__T2           /
    \_____________________B  \____________________/

如果 commits T1, T2, ...Tn没有改变文件，那么所有的P1通过Pn将是 TREESAME 到他们的第一个父级，但不是 TREESAME 到他们的第二个父级。
这意味着所有这些合并提交都出现在--full-history视图中，边缘会立即折叠到较低的历史记录中，而不会引入有趣的单父提交。

--simplify-merges引入了该选项以删除这些额外的合并提交。
通过注意到重写的父节点可以从它们的第一个父节点到达，这些边缘可以被简化。
最后，提交现在看起来像单亲提交，它们对它们的“唯一”父提交是 TREESAME。因此，它们被删除，这个问题不再引起问题。

但是，这最终也会M从历史视图中删除提交！
更糟糕的是，该--simplify-merges选项需要在返回单个结果之前遍历整个历史记录。

许多 Git 用户将 Git 与 Git 服务一起使用，该服务提供代码存储以及针对目标分支的通常称为“拉取请求”或“合并请求”的代码审查工具。

当这些请求被接受并合并时，它们通常会创建一个合并提交，其第一个父级是前一个分支提示，第二个父级是用于请求的主题分支的提示。
这为父级提供了一个有价值的命令，但也使合并提交变得有点特殊。用户可能不仅希望看到哪些提交更改了文件，还希望看到哪些拉取请求将这些提交合并到了他们的分支中。
在前面的示例中，这意味着M除了单父提交“ C”之外，用户还希望看到合并提交“ ”。

当用户在将该功能分支合并到他们的主干之前使用拉取请求合并到一个功能分支时，他们更有可能想要这些合并提交。

从某种意义上说，用户要求“第一个”合并提交以将更改引入他们的分支。只要父订单一致，就可以使用以下规则处理：

“如果它不是 TREESAME 到其第一个父级，而是 TREESAME 到后来的父级，则包括合并提交。”

这些合并看起来像在git pull <topic>主分支上运行“ ”所产生的合并提交。
因此，显示这些提交的选项称为“ --show-pulls”。
这有一个额外的好处，即显示通过在任何 Git 托管和代码审查平台上关闭拉取请求或合并请求创建的提交。

要测试这些选项，请扩展标准测试示例以包含对其第一个父项不是 TREESAME 的合并提交。令人惊讶的是，该选项并未出现在示例中，因为它具有指导意义。

特别是，这个扩展展示了文件历史简化的一个常见问题。当用户使用“ -Xours”或以其他方式忽略冲突的一侧解决合并冲突时，他们会创建一个可能不应该是 TREESAME 的 TREESAME 边。
这导致用户变得沮丧并抱怨“我的更改消失了！”

根据我的经验，向他们展示历史--full-history并--simplify-merges迅速揭示有问题的合并。
如前所述，此选项的计算成本很高。

该--show-pulls选项可能会更快地显示合并提交（通常称为“解决冲突”）。
当然，这取决于具有正确父顺序的用户，当使用git pull master来自主题分支的“ ”时，这是向后的。

将该--show-pulls选项与--simplify-merges.
这需要添加一个新的PULL_MERGE对象标志来存储来自初始 TREESAME 比较的信息。这有助于避免在以后的过滤器中删除这些提交。这包含在测试中，包括如何简化父母。由于 " struct object" 已经通过在 parsed、type 和 flags 成员中使用 33 位破坏了它的 32 位对齐，所以我们不要让它变得更糟。

PULL_MERGE以revision.c与in相同的值 ( 1u<<15)REACHABLE使用commit-graph.c。
REACHABLE 标志仅在编写提交图文件时使用，--show-pulls并且不会在同一进程中使用修订遍历。未来必须小心，以确保这种情况仍然存在。

更新Documentation/rev-list-options.txt有关此选项的重要详细信息。这需要更新历史简化部分中的示例以演示 TREESAME 第二个父代的一些问题。

在此处查看完整示例。