tldr；Cherry在存在冲突的另一个分支中选择提交，需要在新分支中手动解决，这会导致原始提交id不显示在git -cherry -v输出中。我们如何才能显示提交id，从而知道修复已应用于分支？
我正在尝试确定main上的pull请求是否已合并到子分支中。它还有更多，但让我首先给你我们系统的设置。
我们正在使用Azure DevOps Server 2020和git。我们的分支由三个核心分支main、preRelease和currentRelease建立，所有功能和错误分支都是在main分支的基础上创建的。一旦一个工作项(即bug或特性)被验证为通过了所有测试，与该工作项相关的每个拉取请求都会从main中被挑选到preRelease中。
这种设置适用于精心挑选的没有冲突的pull请求，这些请求需要手动协调更改。我们可以使用git cherry -v origin/preRelease origin/main命令来查看两个分支之间存在哪些提交和拉取请求。然后，我们可以过滤掉所有以-开头的cherry列表，然后检查与拉请求id相关联的工作项的状态，以确定它是否处于应该合并到preRelease分支的状态。已经合并的分支将被过滤掉，因为它们在git cherry输出中以+开头。当存在冲突的cherry-pick时，可以看到返回到原始提交和拉取请求的连接不可用，并且没有更新git cherry命令的日志输出以显示提交已合并。
我认为问题可能是当我们将pull请求合并到preRelease分支时，我们如何完成它。然而，在DevOps中尝试不同的选项，Merge no fast forward、Rebase fast forwards和Semi-linear Merge，都导致提交没有显示为preRelease分支的一部分。这让我们相信工作项不是分支的一部分，而实际上它已经被合并到代码中了。
因此，我的问题是，是否有可能利用git和Azure DevOps Server 2020 API来确定提交是否已通过cherry-pick合并到分支中，即使由于合并冲突而被新分支合并。如果有更好的方法来处理整个过程，我愿意接受。我决不是一个git或DevOps大师。如果我们在main和preRelease之间迁移更新的cherry-pick过程是可行的，那么有没有一种方法可以从需要创建一个新分支来处理合并冲突的cherry pick追溯原始提交。注意，当我们创建一个分支来处理合并冲突时，我们从preRelease分支开始，提取最新的代码，然后从preRelease创建一个新的分支，并执行git cherry-pick <commit id>来提取用于合并的代码。也尝试了git cherry-pick -m 1 <commit id>，但在显示原始提交id的提交日志中没有发现任何差异。
git cherry找不到提交，因为提交引入了不同的更改。
假设您精心挑选了一个向文件追加了十行的提交。但后来你试图把它选到一个历史上，在这个历史上，三条线被应用于同一个地方。所以你解决了冲突。但是，由于这三行不同，因此从原始提交到新提交的更改现在有所不同。因此git cherry比较它们的变化(diffs的简化版本)，并且比较失败。
Cherry picks太脆弱了，无法依靠它来传播从开发到预发布和发布的变化。请改用合并。