考虑以下情况：
$ git branch –a
* dev
master
$ git branch --contains 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6
dev
$ git branch --contains f7dfb3689edcaf5f819fa5e691ce13abf858bca8
dev
master
$ git cherry master dev
+ 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6
+ a4e66dbde954f73185d61bfb78b40ac5e61fe56c
+ 6fcffbd9b57e8a74726ea2cd3713f14baaaa06f5
+ 5031ad3cdf2e81c880e9cbf049abed6f1edde3bc
+ dcca33c373df6953ff164e8d70531abd71841278
但是扭曲的是，提交f7dfb3689edcaf5f819fa5e691ce13abf858bca8实际上是从53fdfaf89fca499c36c71d29f25eb1a13b32d4d6中挑选出来的，两者完全相同（请原谅我，因为出于某种原因我们不得不提交2次完全相同的提交id）除了提交消息和提交id之外，两次提交之间没有区别。
现在根据git cherry文档，
将提交与从git patch-id程序获得的补丁ID进行比较。
所以我实际上继续执行git patch-id程序，如下所示
$ git show 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 | git patch-id
bd6c061bd6c380d53832510cbaf68bebb4fb182d 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6
$ git show f7dfb3689edcaf5f819fa5e691ce13abf858bca8 | git patch-id
bd6c061bd6c380d53832510cbaf68bebb4fb182d f7dfb3689edcaf5f819fa5e691ce13abf858bca8
上面的结果显示git patch-id实际上确实认为两个提交是相同的，但git cherry命令仍然无法做到这一点。
我可以看到这种情况发生的唯一原因是git cherry考虑了git patch-id以外的其他因素。
它是否考虑了头部提交的数量（即我的情况下的dev分支）？因为我们在dev分支上有2个版本的提交，而在master上只有1个版本。
答案 0 :(得分：1)
从上面的输出中，您已经将樱桃挑选的修订版合并到dev中（通过在某些时候合并master）。 Git正在遍历修订版本，它现在找到完全匹配并将其从要检查的修订集中删除，并且不为其生成修补程序ID。好消息是git merge仍然认识到dev上的原始更改已经在master中，并且不会尝试重新应用该更改。
我认为在大多数涉及采摘樱桃的工作流程中，您永远不会将包含樱桃采摘的分支合并到您的分支中。你通常会做更多的事情：将修复提交给master，然后挑选一个稳定的分支。或者，在您的情况下，将错误修复提交给master，然后将master合并到dev。
您可以看到git cherry here背后的代码。记下修补程序ID生成here。特别要注意comment on line 719。它将要求master上的修订而不是dev中的修订，因为master被合并到dev中，所以不会是un。因此，不会生成补丁ID。因此，看起来您的原始非樱桃选择修订版尚未被提交给掌握。
你可能会认为这种行为是个错误。但我认为，修复它可能会对性能产生重大影响。