git - cherry-pick 错误修复正确

Question

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

正因为如此，我被引导相信，如果在一个功能分支中修复了一个错误，而另一个开发人员需要这个修复，正确的解决方案是将这个修复挑选到它自己的分支中，然后将该分支 merge 到公共(public)分支两个特征分支都从中分支出来。然后应删除功能分支中的原始 bufix 提交，最后两个功能分支只需重新建立在现在包含错误修复的公共(public)分支之上。

但是，这似乎不是其他人使用 cherry-pick 的解释方式。我认为，如果从一个功能分支中挑选出一个提交到另一个功能分支，并且两者都被 merge 回 common，那么这些单独的提交会导致以下三种情况之一发生；

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

我对 cherry pick 的理解有误吗？

Answer 1

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

如果您将一个分支 rebase 到另一个分支，并且两个提交都引入了相同的更改(从一个分支到另一个分支)， rebase 分支将不包含两个提交，而是 rebase 到历史记录的提交已经介绍过的内容将被排除在外，就像从未介绍过一样。

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