Git 使用cherry pick或rebase-to拾取一系列提交是否会得到相同的结果？

有时我想从不同的存储库中选择一系列提交。我知道两种方法

一,

或

git-rebase——在myBranch上开始结束

我发现第一个版本更容易记住。然而，我读了很多关于采摘樱桃与合并相比是多么的邪恶，因为它打破了历史。但我还没有弄清楚的是，cherry选择一系列提交或使用

--将它们重定为

---

我倾向于认为不应该有什么不同。我弄错了吗？

对合并来说，重定基期和樱桃采摘同样“不好”。它们都会导致忘记您拾取的更改的原始提交的ID；因此，以后的合并可能会多次尝试应用相同的更改。

事实上，在这方面，樱桃采摘比重定基址危害更小。Cherry picking将创建提交的副本，而重定基址将实际移动它们（从而重写历史）

---

两者都比合并更糟糕，在我看来，合并通常是最糟糕的选择。

这两个命令是等效的，您只是在做正常的重新基础所做的工作，以找出要重播到目标分支上的未合并的提交

“它们都会导致忘记您拾取的更改的原始提交的ID；因此，以后的合并可能会多次尝试应用相同的更改。“-这是incorrect@PaulBetts，这是怎么回事？原始ID不会被记录下来；有一些启发式方法可以尝试检测和删除双重应用程序，但基本上如果合并分支A和分支A'（如果“A”是重定基址或将A移到其他头上的结果），则可能会发生额外的合并冲突，并且在历史记录中肯定会有重复提交。重定基址不会“移动”"commits你是说合并是最糟糕的选择吗？即使这是最不坏的选择？重定基址也会创建重复的提交。当你执行

重定基址--on

？Cherry pick也应该检测已经应用的补丁。这两个命令不是不同吗？如果我

git checkout myBranch；git Cherry pick begin..end

，那么我会向前推进myBranch，使其包含cherry pick提交。如果我

git rebase--on myBranch begin end

，那么我将向前推进

end

，并且

myBranch

仍将指向与我启动时相同的提交。作为

cherry pick基础的进程之间是否存在显著差异e> 在最近的一个案例中，
cherry pick
意外地发生了冲突。我中止了，并尝试了等效的
rebase--on
。这很顺利
git checkout myBranch
git cherry-pick begin..end