解决冲突的Cherry-pick提交在git cherry中未显示合并状态的验证方案

Git层面的追溯与确认方法 #

1. 提交消息关联原Commit ID #

手动解决冲突合并时，在新提交的消息中显式添加原Commit ID，示例格式：

Fix [工作项ID]: 修复XX功能缺陷
(cherry picked from commit <原Commit ID>)

后续可通过以下命令快速检索该提交是否存在于preRelease分支：

git log --grep="<原Commit ID>" origin/preRelease

2. 利用git patch-id对比提交内容 #

补丁ID可以识别内容完全一致的提交（即使Commit ID不同），操作步骤：

• 生成原提交的补丁ID：

  git show <原Commit ID> | git patch-id
  

• 遍历preRelease分支提交，对比补丁ID：

  git log origin/preRelease --pretty="%H" | while read commit; do
      git show $commit | git patch-id | grep "<原补丁ID>"
  done
  

若输出匹配结果，说明原提交的内容已等效合并到preRelease。

3. 使用git log --cherry-mark对比分支 #

通过以下命令对比main和preRelease分支，标记内容相同的提交：

git log --cherry-mark --oneline --left-right origin/main...origin/preRelease

其中=标记的是内容完全一致的提交（包括冲突后手动合并的提交），可快速定位原提交是否已纳入目标分支。

Azure DevOps Server 2020 API方案 #

1. 通过工作项关联追溯 #

所有提交均绑定工作项，可通过API关联查询：

• 先获取工作项关联的所有提交：

  GET https://<你的服务器地址>/<项目集合>/<项目>/_apis/wit/workitems/<工作项ID>?api-version=6.0&$expand=relations
  

  从返回的relations中筛选类型为ArtifactLink且url包含git/commit的条目，得到关联提交ID。
• 检查提交是否存在于preRelease分支：

  GET https://<你的服务器地址>/<项目集合>/<项目>/_apis/git/repositories/<仓库ID>/commits/<提交ID>/branches?api-version=6.0
  

  查看返回结果是否包含preRelease分支。

2. 检索分支提交的注释匹配 #

若提交消息已包含原Commit ID，可调用API过滤检索：

GET https://<你的服务器地址>/<项目集合>/<项目>/_apis/git/repositories/<仓库ID>/commits?searchCriteria.branchName=refs/heads/preRelease&searchCriteria.commentContains=<原Commit ID>&api-version=6.0

返回结果非空则说明提交已纳入preRelease分支。

流程优化建议 #

• 强制要求冲突解决后的提交消息必须包含原Commit ID，作为追溯的基础标识。
• 在Azure DevOps中配置分支策略，对合并到preRelease的提交进行消息检查，确保原Commit ID存在。

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