如何 git cherry-pick 一系列提交？

Question

我看到有之间的连接rebase和cherry-pick一系列的提交。

我没有找到任何文章/教程来解释当一个人尝试cherry-pick多次提交时究竟发生了什么。

一些问题（我能想到的）是：

1. 什么是CHERRY_PICK_HEAD参考？
2. 通过运行git cherry-pick 2^..4，git 执行的操作序列是什么以及git 使用的提交之间diff究竟是什么？

3. 通过运行git cherry-pick 1..8，git 会做什么？

Answer 1

樱桃挑选n提交与樱桃挑选一个接一个（使用不同的 git 调用）相同。不涉及分支或其他任何内容，只需在当前分支上为您创建新提交即可。

更多细节

帮助页面https://www.git-scm.com/docs/git-cherry-pick.html说：

给定一个或多个现有提交，应用每个提交的更改，为每个提交记录一个新提交。

让我们把这句话分开：

改变

这有时也被称为“差异”。它git diff HEAD somecommit 会输出什么。有时它也被称为“补丁”（实际上，git diff可以使用通常的patch实用程序来应用相同的输出 - 当然，git apply但这不是这里的重点）。

因此，“更改”是指示工具（例如git或patch如何修改文本文件以最终生成新的、已更改的文本文件）的东西。

您可以通过diff对两个文件运行标准实用程序来创建两个文件之间差异的类似文本表示。事实上，这就是git内部挑选（当然有自己的差异实现）的作用；即这只是一个 2 向差异，而不是像git merge操作中那样的 3 向差异。

每一个介绍

当你有这种状态时：

...----+----+----...
   abc  def          

那么git cherry-pick def改变是提交之间的差异2路abc和def（所有这些不同的，当然，在一个文件通过文件为基础的文件），因为这是def“介绍”。

应用更改

这意味着采取HEAD和“更改”（即差异、补丁等）并创建一组新的文本文件。原则上，您可以将此视为 2 路合并（就像patch实用程序会做的那样），除非它不是，即如果diff输出中的上下文信息与现在的内容不匹配HEAD。在这种情况下，git 会欺骗以找到能够进行 3 向合并的共同祖先，您可以在使用 git 和 meld 进行交互式变基的 3 向合并中的三个文件是什么？. 但是，从用户的角度来看，它仍然无法与git merge结构上的git merge.

记录新提交

git将更改应用于索引和工作目录，并提交。除非 2-way 合并和 3-way 合并没有冲突，否则直接从帮助页面和我的一些评论：

1. 当前分支和 HEAD 指针停留在上次成功提交的位置。[即，只是简单的 HEAD。]
2. CHERRY_PICK_HEAD ref 设置为指向引入难以应用的更改的提交。[这是def我上面的图片。]
3. 干净地应用更改的路径在索引文件和工作树中都会更新。[即，如果在提交中更改了许多文件，那些可以干净地应用的文件是。]
4. 对于冲突路径，索引文件最多记录三个版本，如 git-merge[1] 的“TRUE MERGE”部分所述。工作树文件将包括用通常的冲突标记 <<<<<<< 和 >>>>>>> 括起来的冲突描述。[即，与合并冲突相同，具有一些“凭空变出”的共同祖先。]
5. 没有进行其他修改。

最后，句子的其余部分：

给定一个或多个现有提交，应用...为每个提交记录一个新提交。

如果你给它多次提交，可能是显式的 ingit cherry-pick sha1 sha2 sha3...或隐式的git cherry-pick sha1..sha2，那么上面的只是在一个简单的循环中运行，在最后一个选择之后停止，或者当发生合并冲突时。

你的问题

CHERRY_PICK_HEAD ref 是什么？

2. The CHERRY_PICK_HEAD ref is set to point at the commit that introduced the change that is difficult to apply.

如果它尝试选择 commit def，并且发生合并冲突，CHERRY_PICK_HEAD则将指向def。

通过运行 git cherry-pick 2^..4，git 执行的操作顺序是什么，在哪些提交之间 git 使用 diff？

如上所述：

1. 选择提交 2，即
   • Git 计算 1 和 2 之间的差异。
   • 如果可能，该差异将作为 2 路合并应用到 HEAD 并提交。
   • 如果不可能，该差异将作为 3 路合并应用到 HEAD 并提交。
   • 如果这是不可能的（即合并冲突），那么您只能像往常一样手动解决冲突，它会等待您发出git cherry-pick --continue.
2. 选择提交 3，即......相同。
3. 选择提交 4，即......相同。

通过运行 git cherry-pick 1..8，git 会做什么？

相同，但这次它将选择提交 2、3、4、8。

（范围内的“第一个”提交未被选择的事实是通常的行为，例如git log 2^..4orgit log 1..8将输出相同的提交 - 实际上与将被选择的相同。这在cherry-pick 帮助页面中描述，<commits>包括链接到 git 如何进行修订，了解所有细节。这不是git cherry-pick这些..范围如何工作的属性。）