正确修复樱桃采摘错误

Question

因此，根据我的理解，从一个分支到另一个分支选择提交会创建一个全新的哈希签名，尽管实际的代码更改是相同的。我相信这是因为提交哈希签名取决于分支名称和提交时间。

因此，我被引导相信，如果在功能分支中进行了错误修复并且另一个开发人员需要此修复，正确的解决方案是将这个修复樱桃挑选到它自己的分支中，然后将该分支合并到两个功能分支的共同分支。然后应该删除功能分支中的原始 bufix 提交，最后两个功能分支只需重新基于现在包含错误修复的公共分支。

但是，其他人似乎不是这样解释使用cherry-pick的。我认为如果一个提交是从一个特性分支中挑选出来的，并且两者都合并回公共，那么这些单独的提交会导致三件事之一发生；

• 历史记录中的“重复”提交引入了相同的代码更改
• 必须手动处理的合并冲突
• 引入重复的代码行。

我是否错误地解释了樱桃采摘？

Answer 1

不，如果你从一个分支中挑选一个提交到另一个分支，它会得到不同的哈希值，是的。不是因为分支名称，分支只是粘在提交上的便利贴。但是一个提交的整个历史是哈希计算的一部分，所以两个引入相同更改但在不同历史之上的提交本质上是两个引入相同更改的不同提交。

如果您将一个分支变基到另一个分支，并且两个分支都具有引入相同更改的提交（从一个分支到另一个分支），则变基分支将不会包含两个提交，而是基于更改的历史记录的提交已经引入的将被忽略，就像从未完成一样。

如果您合并分支，则不会因为挑选樱桃而发生冲突，因为两个分支都进行了相同的更改，Git 看到并正确处理了这一点。如果您对同一文件进行其他更改，这些更改可能会产生需要解决的冲突。