简体中文 ▾ 主题 ▾ 最新版本 ▾ git-cherry-pick 最后更新于 2.50.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] 的“真实合并”部分所述。工作区文件将包含用常规冲突标记 <<<<<<< 和 >>>>>>> 括起来的冲突描述。

  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 是一个很好的方式来双重检查 rerere 所做的操作，并在使用单独的 git add 将结果提交到索引之前，捕获潜在的错误合并。

SEQUENCER 子命令

--continue

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

--skip

跳过当前提交，并继续处理序列的其余部分。

--quit

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

--abort

取消操作并返回到 pre-sequence 状态。

示例

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 的所有提交引入的更改应用到工作区和索引，以便可以检查结果，并在合适时将其合并为一个新提交。

以下序列尝试 backport 一个补丁，但由于补丁适用的代码已更改太多而失败，然后再次尝试，这次更加谨慎地匹配上下文行。

$ 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] 套件的一部分