如何使用 GitHub API (octokit) 过滤立即影响主分支的提交？答案

【问题标题】：How can I use the GitHub API (octokit) to filter commits that immediately affect the master branch?如何使用 GitHub API (octokit) 过滤立即影响主分支的提交？
【发布时间】：2013-11-11 22:33:55
【问题描述】：

我正在使用 TeamCity 和 Github 自动化语义版本控制，并且我正在尝试找到一种方法来计算直接影响 master 分支的提交。

这个来自 Git-Extensions 的带注释的屏幕截图可能是最好的解释。我想自动计算箭头中的版本号：

我在构建过程中使用 ruby 和 octokit 来查询 GitHub API。当提交或合并符合主要/次要版本时，主要和次要版本号会手动递增，因此伪代码基本上是：

找到major.minor.0对应的commit
计算自 major.minor.0 以来更改主分支状态的每个提交
将补丁版本设置为commits.count

我遇到的问题是，如果我只计算提交给 master 的次数，每次接受拉取请求时，提交计数都会增加 n+1，其中 n 是提交到分支的数量。这会起作用，但它......不优雅。是的，我知道当您接受拉取请求时，您实际上是在接受该分支的整个历史记录作为您的“主”历史记录的一部分，但对于版本控制而言，这并不重要。

有谁知道我如何通过 GitHub API 过滤提交，以查明提交是否在创建时直接影响 master，或者是否有某种原因这实际上是不可能的？ p>

谢谢！

【问题讨论】：

这是个好问题。不确定最好的方法是什么，并且在某些情况下可能无法做到。例如，如果您在问题中拥有的那个提交图除了 master 之外没有任何分支引用 - 您将不知道在哪里放置版本箭头，因为您不知道哪些提交在 master 上。这种情况可能经常发生，因为在有人将分支合并到 master 之后 - 他们可能会删除它。所以你只剩下一个带有单个分支 (=master) 的大型复杂图。
所以，归根结底，问题在于 git 分支只不过是指向单个提交的指针。您不知道过去哪些分支指向了某个提交。您只能判断某个提交是否可以从某个分支 (=commit) 访问。

标签： git github github-api semantic-versioning octokit

【解决方案1】：

我做过类似的事情。实际上，您可以使用以下思想递归获取每个 pull-request 的提交 Sha：

var filter = new PullRequestRequest() { State = ItemState.Closed }; //for my example, I filtered the pull-requests that are closed
var prs =await client.Repository.PullRequest.GetAllForRepository(Owner,Name,filter);
foreach(var pr in prs){
var prs2 = await client.Repository.PullRequest.Commits (Owner, Name, pr.Number);
}

之后，您将获得 prs2 Sha 属性并将其存储到列表中。然后你就得到了 repo 的所有提交。

var commits = await client.Repository.Commit.GetAll (Owner, Name);

最后，您会将列表与拉取请求中提交的 sha 进行比较，并将它们从包含 repo 的所有提交的列表中排除。这样，只会留下不在拉取请求中的提交。或者，您可以检查这些提交是否是合并提交（合并另一个贡献者的拉取请求的提交）并排除它们。

【讨论】：