因此，根据我的理解，从一个分支到另一个分支的提交会创建一个全新的哈希签名，尽管实际的代码更改是相同的。我相信这是因为提交哈希签名取决于分支名称和提交时间等。
正因为如此，我被认为如果在功能分支中进行了错误修复而另一个开发人员需要此修复，那么正确的解决方案是将此修复程序选择到其自己的分支中，并将该分支合并到公共分支的两个特征分支分支。然后应删除功能分支中的原始修补提交，最后两个功能分支只是重新基于现在包含错误修复的公共分支。
然而，似乎这并不是其他人使用樱桃选择的解释。我认为，如果从一个功能分支中挑选出一个提交到另一个功能分支，并且两者都合并回公共，那么这些单独的提交会导致三种情况之一发生;
我是否错误地解释了樱桃选择？
答案 0 :(得分：2)
不，如果你从一个分支到另一个分支中挑选一个提交，它会得到一个不同的哈希，是的。不是因为分支名称，分支只是一个坚持提交的post-it。但是提交的整个历史记录是哈希计算的一部分，所以两个提交引入相同的更改但在不同的历史记录之上基本上是两个不同的提交引入相同的更改。
如果你将一个分支重新绑定到另一个分支，并且两个分支都有引入相同更改的提交（从一个分支到另一个分支），则重新分支的分支将不包含这两个提交，但是将提交重新定位到更改的历史记录中已经介绍的将被遗漏，就像从未做过一样。
如果你合并了分支，就不会因为挑选樱桃而产生冲突，因为两个分支都做了相同的更改，Git看到并正确处理了这个。如果对同一文件进行其他更改，则这些更改可能会产生需要解决的冲突。