Git
英语 ▾ 主题 ▾ 最新版本 ▾ git-cherry-pick 最后更新于 2.45.0

名称

git-cherry-pick - 应用某些现有提交引入的变更

概要

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

描述

给定一个或多个现有提交，应用每个提交引入的变更，为每个变更记录一个新的提交。这要求您的工作树干净（没有来自 HEAD 提交的修改）。

当无法明显应用变更时，会发生以下情况：

  1. 当前分支和 HEAD 指针停留在最后成功创建的提交上。

  2. CHERRY_PICK_HEAD ref 设置为指向引入难以应用变更的提交。

  3. 变更干净应用的路径将在索引文件和您的工作树中更新。

  4. 对于冲突路径，索引文件将记录最多三个版本，如 git-merge[1] 的“TRUE MERGE”部分所述。工作树文件将包括冲突的描述，用通常的冲突标记 <<<<<<< 和 >>>>>>> 括起来。

  5. 没有进行其他修改。

有关如何解决此类冲突的提示，请参见 git-merge[1]。

选项

<commit>…​

要 cherry-pick 的提交。有关指定提交的更完整列表，请参见 gitrevisions[7]。可以传递提交集，但默认情况下不执行遍历，就像指定了 --no-walk 选项一样，请参见 git-rev-list[1]。请注意，指定范围将向单个修订版遍历提供所有 <commit>…​ 参数（请参见后面使用 maint master..next 的示例）。

-e
--edit

使用此选项，git cherry-pick 允许您在提交之前编辑提交消息。

--cleanup=<mode>

此选项确定在将提交消息传递给提交机制之前如何清理提交消息。有关更多详细信息，请参见 git-commit[1]。特别是，如果 <mode> 的值为 scissors，则在发生冲突的情况下，剪刀将附加到 MERGE_MSG，然后再传递。

-x

在记录提交时，在原始提交消息中附加一行，内容为“(cherry picked from commit …​)”，以指示从哪个提交 cherry-pick 此变更。仅对没有冲突的 cherry-pick 执行此操作。如果您是从私有分支 cherry-pick，请勿使用此选项，因为此信息对接收者毫无用处。另一方面，如果您是在两个公开可见的分支之间 cherry-pick（例如，将修复程序从开发分支 backport 到旧版本的维护分支），则添加此信息可能会很有用。

-r

以前，此命令默认执行上述 -x，而 -r 用于禁用它。现在默认情况下不执行 -x，因此此选项是无效操作。

-m <parent-number>
--mainline <parent-number>

通常，您无法 cherry-pick 合并，因为您不知道合并的哪一边应该被视为主线。此选项指定主线的父级编号（从 1 开始），并允许 cherry-pick 相对于指定的父级重放变更。

-n
--no-commit

通常，此命令会自动创建一系列提交。此标志将应用 cherry-pick 每个命名提交到您的工作树和索引所需的变更，但不创建任何提交。此外，使用此选项时，您的索引不必与 HEAD 提交匹配。cherry-pick 相对于索引的初始状态执行。

这在一次 cherry-pick 多个提交的效果到您的索引时非常有用。

-s
--signoff

在提交消息末尾添加 Signed-off-by 尾部。有关更多信息，请参见 git-commit[1] 中的 signoff 选项。

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

GPG 签署提交。keyid 参数是可选的，默认为提交者身份；如果指定，它必须与选项粘贴在一起，中间没有空格。--no-gpg-sign 用于抵消 commit.gpgSign 配置变量和之前的 --gpg-sign。

--ff

如果当前 HEAD 与 cherry-pick 的提交的父级相同，则将执行对此提交的快进。

--allow-empty

默认情况下，cherry-pick 空提交将失败，表明需要显式调用 git commit --allow-empty。此选项会覆盖此行为，允许在 cherry-pick 中自动保留空提交。请注意，当“--ff”有效时，即使没有此选项，满足“快进”要求的空提交也会被保留。另请注意，使用此选项仅保留最初为空的提交（即，提交记录与父级相同的树）。由于先前的提交导致空提交的提交将导致 cherry-pick 失败。要强制包含这些提交，请使用 --empty=keep。

--allow-empty-message

默认情况下，cherry-pick 具有空消息的提交将失败。此选项会覆盖此行为，允许 cherry-pick 具有空消息的提交。

--empty=(drop|keep|stop)

如何处理 cherry-pick 冗余于当前历史记录中已有的变更的提交。

drop

提交将被丢弃。

keep

提交将被保留。暗示 --allow-empty。

stop

当应用提交时，cherry-pick 将停止，允许您检查提交。这是默认行为。

请注意，--empty=drop 和 --empty=stop 仅指定如何处理最初不为空的提交，而是由于先前的提交而变为空的提交。最初为空的提交仍将导致 cherry-pick 失败，除非指定 --empty=keep 或 --allow-empty 中的其中之一。

--keep-redundant-commits

--empty=keep 的弃用同义词。

--strategy=<strategy>

使用给定的合并策略。应该只使用一次。有关详细信息，请参见 git-merge[1] 中的 MERGE STRATEGIES 部分。

-X<option>
--strategy-option=<option>

将合并策略特定的选项传递给合并策略。有关详细信息，请参见 git-merge[1]。

--rerere-autoupdate
--no-rerere-autoupdate

在 rerere 机制重用当前冲突的记录解决方案以更新工作树中的文件后，允许它也使用解析结果更新索引。--no-rerere-autoupdate 是一个很好的方法，可以在使用单独的 git add 将结果提交到索引之前，仔细检查 rerere 所做的操作并捕获潜在的错误合并。

SEQUENCER 子命令

--continue

使用 .git/sequencer 中的信息继续正在进行的操作。 可用于在解决冲突后继续失败的 cherry-pick 或 revert 操作。

--skip

跳过当前提交并继续执行序列的其余部分。

--quit

忘记正在进行的操作。 可用于在失败的 cherry-pick 或 revert 操作后清除 sequencer 状态。

--abort

取消操作并返回到操作前的状态。

示例

git cherry-pick master

应用 master 分支尖端的提交所引入的更改，并使用此更改创建一个新的提交。

git cherry-pick ..master
git cherry-pick ^HEAD master

应用 master 的祖先，但不是 HEAD 的祖先的所有提交所引入的更改，以生成新的提交。

git cherry-pick maint next ^master
git cherry-pick maint master..next

应用 maint 或 next 的祖先，但不是 master 或其任何祖先的所有提交所引入的更改。 请注意，后者并不意味着 maint 和 master 和 next 之间的所有内容； 特别是，如果 maint 包含在 master 中，则不会使用 maint。

git cherry-pick master~4 master~2

应用 master 指向的第五个和第三个最近提交所引入的更改，并使用这些更改创建 2 个新的提交。

git cherry-pick -n master~1 next

将 master 指向的倒数第二个提交和 next 指向的最后一个提交所引入的更改应用到工作树和索引，但不使用这些更改创建任何提交。

git cherry-pick --ff ..next

如果历史记录是线性的并且 HEAD 是 next 的祖先，则更新工作树并将 HEAD 指针前进以匹配 next。 否则，将 next 中但不在 HEAD 中的那些提交所引入的更改应用于当前分支，为每个新的更改创建一个新的提交。

git rev-list --reverse master -- README | git cherry-pick -n --stdin

将 master 分支上所有影响 README 的提交所引入的更改应用于工作树和索引，以便可以检查结果，如果合适，可以将其作为单个新提交。

以下序列尝试回退补丁，因为补丁应用的代码发生了太大变化而退出，然后再次尝试，这次更加小心地匹配上下文行。

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git cherry-pick --abort            (3)
$ git cherry-pick -Xpatience topic^  (4)

  1. 应用 git show topic^ 所显示的更改。 在此示例中，补丁无法干净地应用，因此有关冲突的信息将写入索引和工作树，并且不会产生新的提交。

  2. 总结要协调的更改。

  3. 取消 cherry-pick。 换句话说，返回到 cherry-pick 之前的状态，保留您在工作树中所做的任何本地修改。

  4. 尝试再次应用 topic^ 所引入的更改，花费更多时间避免基于不正确匹配上下文行的错误。

另请参见

git-revert[1]

GIT

是 git[1] 套件的一部分

scroll-to-top