English ▾ 主题 ▾ 最新版本 ▾ 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 引用被设置为指向引入难以应用的更改的提交。

  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，则在发生冲突的情况下，scissors 将被附加到 MERGE_MSG，然后再传递。

-x

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

-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 仅指定如何处理最初不为空，而是由于先前的提交而变为空的提交。 除非指定了 --empty=keep 或 --allow-empty 之一，否则最初为空的提交仍将导致 cherry-pick 失败。

--keep-redundant-commits

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

--strategy=<strategy>

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

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

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

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

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

序列器子命令

--continue

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

--skip

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

--quit

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

--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 中，则不会使用它。

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