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 以及 masternext 之间的所有内容; 特别是,如果 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

属于 git[1] 套件的一部分

scroll-to-top