Git Cherry Pick vs Rebase

自从git cherry-pick学习了能够应用多个提交的时间以来，这种区分确实变得有些争议了，但这就是所谓的收敛进化;-)

真正的区别在于创建这两种工具的原始意图：

• git rebase的任务是将开发人员在其私有存储库中针对上游分支的X版本创建的一系列更改转发到同一分支的Y版本（Y> X）。这有效地改变了该系列提交的基础，因此“变基础”。

  （它还允许开发人员将一系列提交移植到任意提交上，但这不太明显。）

• git cherry-pick是为了将有趣的承诺从一个开发线带到另一个开发线。一个典型的例子是将在不稳定的开发分支上进行的安全修补程序反向移植到稳定的（维护）分支，在该分支上merge没有意义，因为这会带来很多不必要的更改。

  自首次出现以来，git cherry-pick就能够一次一次地拾取多个提交。

因此，这两个命令之间最显着的差异可能是它们如何对待工作的分支：git cherry-pick通常从其他地方带来提交，并将其应用于当前分支之上，记录新提交，同时git rebase获取当前分支并重写一系列自己的提示以一种或另一种方式提交。是的，这是对git rebase可以做什么的沉闷描述，但这是有意的，试图使一般想法沉入其中。

更新以进一步说明git rebase正在讨论的使用示例。

在这种情况下，

《书》指出：

但是，还有另一种方法：您可以对C3中引入的更改进行修补，然后将其重新应用到C4之上。在Git中，这称为变基。使用rebase命令，您可以将在一个分支上提交的所有更改都应用到另一分支上。

在此示例中，您将运行以下命令：

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

这里的“陷阱”是，在此示例中，“实验”分支（用于重新定标的主题）最初是从“主”分支分支而来的，因此它与之共享提交C0到C2-实际上，“实验”为“最高”（包括C2并在其之上提交C3）。（这是最简单的情况；当然，“实验”可以在其原始基础上包含数十个提交。）

现在git rebase被告知将“实验”重新建立到“大师”的当前提示上，git rebase如下所示：

1. 运行git merge-base以查看“实验”和“大师”共享的最后一次提交是什么（换句话说，这是转移的重点）。这是C2。
2. 节省了自转移点以来的所有提交；在我们的玩具示例中，它只是C3。
3. 倒退HEAD（在操作开始之前指向“ experiment”的尖端提交）以指向“ master”的尖端-我们正在此基础上。
4. 尝试git apply按顺序应用每个已保存的提交（就像使用一样）。在我们的玩具示例中，这只是一次提交，即C3。假设其应用程序将生成提交C3'。
5. 如果一切顺利，则将“实验”引用更新为指向由应用最后保存的提交（在本例中为C3'）而产生的提交。

现在回到您的问题。如您所见，从技术上讲 ，这里git rebase的确确实是将一系列提交从“实验”移植到“大师”的尖端，因此您可以正确地告诉我们在此过程中确实存在“另一个分支”。但是要点在于，来自“实验”的技巧提交最终成为“实验”中的新技巧提交，它只是改变了基础：

再次，从技术上讲，您可以说git rebase这里合并了“ master”的某些提交，这是绝对正确的。