因此，根据我的理解，从一个分支到另一个分支挑选提交会创建一个 全新的哈希签名 尽管实际代码更改是相同的。我相信这是因为提交哈希签名取决于分支名称和提交时间等。
正因为如此，我相信如果在功能分支中进行了错误修复并且另一个开发人员需要此修复，正确的解决方案是将此修复挑选到自己的分支中，然后将该分支 merge 到公共(public)分支中两个特征分支都从其分支。然后应该删除功能分支中的原始 bufix 提交，最后两个功能分支都简单地重新基于现在包含错误修复的公共(public)分支。
然而，这似乎不是其他人使用cherry-pick解释的方式。我认为如果一个提交是从一个特性分支中挑选出来的，并且两者都被 merge 回共同的 ，那么这些单独的提交会导致以下三种情况之一发生；
我是否错误地解释了樱桃选择？
最佳答案
不，如果你从一个分支中挑选一个提交到另一个分支，它会得到一个不同的哈希，是的。不是因为分支名称，分支只是一个贴在提交上的便利贴。但是提交的整个历史记录是哈希计算的一部分，因此引入相同更改但在不同历史记录之上的两个提交本质上是引入相同更改的两个不同提交。
如果您将一个分支 rebase 到另一个分支，并且两者都有引入相同更改的提交(从一个分支到另一个分支)，重基分支将不会包含两个提交，而是重基到已引入更改的历史记录的提交将被排除在外，就像从未做过一样。
如果 merge 分支，则不会因为挑选而产生冲突，因为两个分支都做了相同的更改，Git 会看到并正确处理这一点。如果您对同一文件进行其他更改，这些更改可能会产生需要解决的冲突。
关于git - cherry-pick 错误修复正确，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39289336/