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) 的"真正的合并"部分所述。工作树文件将包含由通常的冲突标记 <<<<<<< 和 >>>>>>> 包围的冲突描述。
5. 不进行其他修改。

有关解决此类冲突的一些提示，请参阅 git-merge(1)。

选项

<commit>...

要 cherry-pick 的提交。有关指定提交的更完整方式列表，请参阅 gitrevisions(7)。可以传递提交集但默认不进行遍历，如同指定了 --no-walk 选项，请参阅 git-rev-list(1)。请注意，指定范围会将所有 <commit>... 参数提供给单次修订遍历。

-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（例如将修复向后移植到旧版本的维护分支），添加此信息可能很有用。

-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 签名提交。

--ff

如果当前 HEAD 与 cherry-pick 的提交的父提交相同，则执行到该提交的快进。

--allow-empty

默认情况下，cherry-pick 空提交将失败，指示需要显式调用 git commit --allow-empty。此选项覆盖该行为，允许在 cherry-pick 中自动保留空提交。

--allow-empty-message

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

--empty=(drop|keep|stop)

如何处理与当前历史中已存在的更改冗余的被 cherry-pick 的提交：

• drop：提交将被丢弃。
• keep：提交将被保留。隐含 --allow-empty。
• stop：当应用提交时 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 机制在当前冲突上重用记录的解决方案以更新工作树中的文件后，允许它也使用解决方案的结果更新索引。

序列器子命令

--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 或其任何祖先的提交引入的更改。

• 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 cherry-pick topic^             <1>
$ git diff                           <2>
$ git cherry-pick --abort            <3>
$ git cherry-pick -Xpatience topic^  <4>

另请参阅

git-revert(1)

Git

git(1) 套件的一部分