我正在使用TeamCity和Github自动进行语义版本控制,而我正试图找到一种计算直接影响主分支的提交的方法。
可能是Git-Extensions的这个带注释的截图最好的解释。我想自动计算箭头中的版本号:
我正在使用ruby和octokit来查询GitHub API作为构建过程的一部分。当提交或合并有资格作为主要/次要版本时,主要版本号和次要版本号会手动递增,因此伪代码基本上是:
我遇到的问题是,如果我只计算要提交的提交,则每次接受拉取请求时,提交计数会递增 n + 1 ,其中 n < / em>是对分支的提交数。这会起作用,但它......不太优雅。是的,我理解当您接受拉取请求时,您实际上已接受该分支的整个历史记录作为“主”历史记录的一部分,但出于版本控制目的无关紧要。
有没有人知道如何通过GitHub API过滤提交,以确定提交是否直接影响 master ,或者是否有某些原因实际上这是不可能的?
谢谢!
答案 0 :(得分: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属性并将其存储到列表中。 然后你得到了回购的所有提交。
var commits = await client.Repository.Commit.GetAll (Owner, Name);
最后,您将把列表与pull-requests中提交的sha进行比较,并将它们从包含repo所有提交的列表中排除。这样,只会留下不在pull-request中的提交。或者,您可以检查这些提交是否是合并提交(提交合并另一个贡献者的提取请求)并将其排除。