2

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

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

git 扩展截图

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

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

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

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

谢谢！

4

1 回答 1

0

我做过类似的事情。您实际上可以使用以下思想递归地获取每个 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 的所有提交的列表中排除。这样，只会留下不在拉取请求中的提交。或者，您可以检查这些提交是否是合并提交（合并另一个贡献者的拉取请求的提交）并排除它们。

于 2016-05-11T11:41:01.783 回答