GitHub/GitLab REST API - 获取分支直接合并到 Master

Question

假设我们有 Master、develop、feature1、feature2、feature3、bugfixing1、bugfixing2 等分支……

GitLab/GitHub 是否提供 API 来让我们知道哪些分支直接合并到 Master 分支？

注意：我们正在尝试实现一个工具来确定哪些分支直接合并到 Master 分支中。 与 Git 对话的一种方式是 REST API。

例子：

• 开发、功能 2、错误修复 1 合并到主分支

• 只开发合并到主分支

• 没有分支合并到主分支

非常感谢。

Answer 1

TL; 博士

不要为此使用 REST API。 ¹ Git 没有。 使用git branch --merged 。 但要注意它的实际作用。

---

¹如果您确实使用了一个，请注意它几乎肯定只使用git branch --merged或内部等效项。 另外，请注意托管服务器 A 上的 REST API 与托管服务器 B 上的不同，后者与托管服务器 C 上的不同。托管服务器 D 没有 API。 但是 Git 可以在本地完成它，无论您的托管服务器如何，这都可以工作。

---

长

Git 中不存在分支。

好吧，这显然不是真的：它们确实存在。 但在一个非常重要的方面，它们并不重要。 只有提交才真正重要。 分支名称主要用于查找提交。 合并是通过合并提交来完成的，即使您在过程中使用了分支名称。 所以诀窍是先问关于提交的问题。 只有在得到答案之后，您才应该开始想知道分支名称。

正因为如此，通常不可能说哪个分支被合并了。 但是很容易判断是否合并了某个特定的提交。 而且，一个分支名称，如master或develop ，总是准确地标识一个提交。 只是master标识的特定提交随时间发生变化。 develop标识的特定提交也是如此， feature2标识的特定提交也是如此，依此类推。

从图片上看，这些东西可能是这样的：

       I--J   <-- feature1
      /
...--H   <-- master
      \
       K--L   <-- feature2

在这里， feature1和feature2都没有合并到master 。 这是因为由名称feature1标识的提交，即提交J —— J代表它的实际哈希 ID，它是一些丑陋的字母和数字字符串——不是提交H的祖先，它是由以下代码标识的提交master 。 但是， master被合并到feature1 ，因为提交H是提交J的祖先。 同样， master合并到feature2 。

如果我们现在使用：

git checkout master
git merge --ff-only feature1
git merge --no-ff feature2

在命令行上，一切正常，我们得到一个新的合并提交M ，以便名称master现在指向这个合并提交：

       I--J   <-- feature1
      /    \
...--H      M   <-- master
      \    /
       K--L   <-- feature2

请注意我们所做的只是向绘图添加一个提交：新提交M指向现有提交J和L 。 分支名称master现在标识提交M ，而不是提交H 。

由于J和L都是M祖先，但M不是两者的祖先，因此分支feature1和feature2现在合并到master 。 请注意，此时，我们可以删除名称feature1 ：

       I--J
      /    \
...--H      M   <-- master
      \    /
       K--L   <-- feature2

提交J仍然是提交M的祖先，因此提交被合并。 但是分支feature1不再存在。 使用Git 无关紧要，但是现在，标识作为M祖先的提交的分支名称列表不再包含feature1 。 我们可以对feature2做同样的feature2 ：

       I--J
      /    \
...--H      M   <-- master
      \    /
       K--L

我们现在可以创建一个新的分支名称，例如feature/short ，指向提交J ：

       I--J   <-- feature/short
      /    \
...--H      M   <-- master
      \    /
       K--L

Commit J仍然是 commit M的祖先，因此分支feature/short合并到分支master 。

Git 本身——不是 GitHub 也不是 GitLab，只是普通的旧 Git——可以告诉你哪些分支名称指向作为其他分支名称的祖先的提交：

git branch --merged master

首先找到提交M ，然后遍历所有分支名称——在这种情况下， feature/short是唯一剩下的其他分支名称——以查看这些分支名称标识的提交是否是提交M的祖先。 目前， feature/short也是如此，因此git branch --merged将列出feature/short 。

但是，如果我们git checkout feature/short并对其进行新的提交，我们会得到：

       I--J---N   <-- feature/short
      /    \
...--H      M   <-- master
      \    /
       K--L

提交N不是提交M的祖先，因此分支feature/short不会合并到分支master 。 运行git branch --merged master将不再列出feature/short 。

远程跟踪名称

要从您自己的 Git 存储库而非某些托管服务 API 执行此操作，您需要从托管服务克隆 Git 存储库。 当你做出这样的克隆，除非你用--mirror ^，2使用Git将重新命名其分支机构。 您将拥有一系列远程跟踪名称，而不是分支名称，形式为origin/master 、 origin/develop 、 origin/feature1等。

将他们的提交复制到您的存储库并将其分支名称重命名为您的远程跟踪名称后，您自己的 Git 将在您的存储库中创建一个分支名称，指向您从他们那里获得的现有提交之一。 默认情况下，您的 Git 将创建您的master指向与它们的origin/master相同的提交。 但是，随着时间的推移，它们的分支名称会发生​​变化：它们将指向更新、更好用的提交。 您将需要运行：

git fetch

或者：

git fetch --prune

让您的 Git 接收他们的新提交并更新您的远程跟踪名称。 使用--prune将确保您的 Git删除旧的、陈旧的远程跟踪名称：例如，在他们的 Git 删除了他们的feature/short ，您的 Git 将继续拥有origin/feature/short直到您使用修剪进行提取打开。 然后您的 Git 会注意到它们没有feature/short并删除您的origin/feature/short 。

您在这里要做的是使用：

git branch --merged -r origin/master

-r选项告诉git branch查看您的远程跟踪名称而不是您的分支名称。 该origin/master告诉你的Git使用提交您的origin/master -their master为你上次读取更新标识。 所以现在你会得到一个像origin/feature1和origin/master这样的列表作为远程跟踪名称，指向提交的提交，这些提交是你的origin/master指向的提交的祖先。

---

²您不太可能想要使用--mirror 。

Answer 2

我们看到 GitLab 支持 API 来获取项目的所有合并请求。 但是，我们没有看到 GitHub 的类似 API。

https://docs.gitlab.com/ee/api/merge_requests.html#list-project-merge-requests

curl -XGET --header "PRIVATE-TOKEN: XXX" " https://gitlab.com/api/v4/projects/6888/merge_requests "

https://github.community/t5/GitHub-API-Development-and/Get-all-merge-requests-for-a-project-OR-get-branches-merged/mp/42869