使用Azure DevOps Get Commit API查询指定日期范围返回结果超出预期

不少开发者都遇到过类似问题，大概率是日期格式、时区或API参数逻辑导致的，给你几个具体排查方向：

1. 日期格式与时区解析歧义 #

Azure DevOps API 默认按UTC时区解析日期，如果你用MM/DD/YYYY这类本地时间格式，很容易因为时区转换扩大筛选范围。比如你输入的06/12/2023 12:41 PM是本地时间，API可能会解析为UTC当天下午4点左右，从而包含更多不在你预期范围内的提交。

解决办法：
将日期转换为UTC时区的ISO 8601格式（yyyy-MM-ddTHH:mm:ssZ），这是API最认可的格式，能避免解析错误。在PowerShell中可以这么处理：

# 把本地日期转成UTC并格式化为ISO 8601标准格式
$baselineCommitDateUTC = $baselineCommitDate.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
$latestCommitDateUTC = $latestCommitDate.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")

# 替换到请求URL中
$apiUrl = "https://dev.azure.com/$organization/$project/_apis/git/repositories/$repository/commits?searchCriteria.fromDate=$baselineCommitDateUTC&searchCriteria.toDate=$latestCommitDateUTC&searchCriteria.includeWorkItems=$true&api-version=6.1-preview.1"

2. 混淆「作者日期」与「提交日期」 #

API的searchCriteria.fromDate和toDate默认筛选的是提交日期（committer date），也就是代码推送到仓库的时间；而你统计的可能是作者日期（author date）——本地编写代码时的提交时间。这两个日期经常存在差异（比如延迟推送），导致筛选范围不符。

解决办法：
如果需要按作者日期筛选，改用API的searchCriteria.authorDateFrom和searchCriteria.authorDateTo参数，替换原来的fromDate和toDate。

3. 分页默认返回100条的影响 #

Azure DevOps Git API 默认每页返回100条结果（$top=100），如果你的日期范围内实际提交数确实超过60，但你误以为是60，就会出现「超出预期」的错觉。可以手动指定$top参数限制返回数量，同时检查返回结果里的continuationToken，确认是否有多页数据。

示例URL：

https://dev.azure.com/$organization/$project/_apis/git/repositories/$repository/commits?searchCriteria.fromDate=$baselineCommitDateUTC&searchCriteria.toDate=$latestCommitDateUTC&searchCriteria.includeWorkItems=$true&$top=60&api-version=6.1-preview.1

4. PowerShell变量替换的问题 #

检查PowerShell是否正确处理了日期变量里的空格或特殊字符，比如日期中的空格需要转义为%20。可以输出最终的API URL，复制到浏览器里直接访问，看返回结果是否符合预期，排除脚本变量替换的错误。

内容的提问来源于stack exchange，提问作者Samuel Palmer