Azure DevOps Git Commits Batch API按路径过滤丢失结果问题排查

核心问题根源 #

• API过滤逻辑的"全路径匹配"特性：7.1-preview.1版本的Commits Batch API中，itemPath参数的过滤逻辑是仅返回所有变更路径都完全落在指定路径下的提交。如果提交同时包含aspnet-core和其他根路径的文件变更，API会判定该提交不符合过滤条件，直接排除——这就是你看到的"符合条件但丢失"的核心原因。
• 合并提交的变更处理缺陷：合并提交的变更集通常包含来自多个父分支的修改，API在处理这类提交的路径过滤时，可能没有完整遍历所有关联的变更项，或者对合并提交的变更记录采用了不同的校验逻辑，导致即使包含目标路径的变更，也会被过滤掉。

验证步骤 #

1. 取一个丢失的提交ID，调用Git Changes API确认变更内容：

   GET https://dev.azure.com/{org}/{proj}/_apis/git/repositories/{repoId}/commits/{commitId}/changes?api-version=7.1-preview.1
   

   检查返回的变更列表，确认确实包含aspnet-core路径下的文件。
2. 对比带itemPath和不带itemPath的Commits Batch API返回结果，验证过滤逻辑的差异。

可行解决方法 #

• 本地二次过滤：先调用不带itemPath参数的Commits Batch API获取所有分支对比的提交，然后在本地遍历每个提交的变更列表，筛选出包含aspnet-core路径的提交。这种方法虽然会多获取一些数据，但能100%保证不遗漏符合条件的提交。
• 尝试通配符路径：将itemPath设置为aspnet-core/**（递归匹配子路径），部分场景下可以触发API的部分匹配逻辑，但注意这不是官方明确支持的特性，不同版本可能有差异。
• 强制包含合并提交：在API请求中添加searchCriteria.includeMergeCommits=true参数（默认可能为true，但明确指定可以避免API的隐性逻辑判断），尝试让合并提交的变更被正确识别。

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