设置和配置
获取和创建项目
基本快照
分支与合并
共享和更新项目
检查和比较
打补丁
调试
电子邮件
外部系统
服务器管理
指南
管理
底层命令
- 2.50.1 无更改
-
2.50.0
2025-06-16
- 2.45.1 → 2.49.1 无更改
-
2.45.0
2024-04-29
- 2.39.4 → 2.44.4 无更改
-
2.39.3
2023-04-17
- 2.38.1 → 2.39.2 无更改
-
2.38.0
2022-10-02
- 2.35.1 → 2.37.7 无更改
-
2.35.0
2022-01-24
- 2.30.1 → 2.34.8 无更改
-
2.30.0
2020-12-27
- 2.27.1 → 2.29.3 无更改
-
2.27.0
2020-06-01
- 2.23.1 → 2.26.3 无更改
-
2.23.0
2019-08-16
- 2.22.1 → 2.22.5 无更改
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 无更改
-
2.21.0
2019-02-24
- 2.10.5 → 2.20.5 无更改
-
2.9.5
2017-07-30
- 2.8.6 无更改
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
- 2.4.12 → 2.5.6 无更改
-
2.3.10
2015-09-28
- 2.1.4 → 2.2.3 无更改
-
2.0.5
2014-12-17
概要
git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff] [-S[<keyid>]] <commit>… git cherry-pick (--continue | --skip | --abort | --quit)
描述
给定一个或多个现有提交,应用每个提交引入的更改,并为每个更改记录一个新的提交。这要求您的工作树是干净的(没有对 HEAD 提交的修改)。
当如何应用更改不明显时,会发生以下情况:
-
当前分支和
HEAD
指针保留在最后一次成功提交的位置。 -
CHERRY_PICK_HEAD
引用被设置为指向引入难以应用更改的提交。 -
更改已干净应用的文件路径会在索引文件和您的工作树中都进行更新。
-
对于冲突路径,索引文件会记录最多三个版本,如 git-merge[1] 的“真实合并”部分所述。工作树文件将包含冲突描述,并用通常的冲突标记 <<<<<<< 和 >>>>>>> 括起来。
-
没有进行其他修改。
有关解决此类冲突的一些提示,请参阅 git-merge[1]。
选项
- <提交>…
-
要拣选的提交。有关更完整的提交拼写方式列表,请参阅 gitrevisions[7]。可以传递提交集,但默认情况下不进行遍历,就像指定了
--no-walk
选项一样,请参阅 git-rev-list[1]。请注意,指定一个范围会将所有 <提交>… 参数提供给一次单独的修订遍历(请参阅后面使用 maint master..next 的示例)。 - -e
- --edit
-
使用此选项,git cherry-pick 将允许您在提交之前编辑提交消息。
- --cleanup=<模式>
-
此选项决定了提交消息在传递给提交机制之前如何清理。有关更多详细信息,请参阅 git-commit[1]。特别是,如果 <模式> 的值为
scissors
,则在发生冲突时,MERGE_MSG
在传递之前将附加剪刀线。 - -x
-
记录提交时,在原始提交消息后附加一行 "(cherry picked from commit …)",以指示此更改是从哪个提交拣选的。这仅适用于没有冲突的拣选。如果您从私人分支拣选,请勿使用此选项,因为此信息对接收方无用。另一方面,如果您在两个公开可见的分支之间拣选(例如,将针对旧版本的维护分支的修复从开发分支回溯),添加此信息可能很有用。
- -r
-
以前,该命令默认执行上述
-x
,而-r
用于禁用它。现在默认不执行-x
,因此此选项是空操作(no-op)。 - -m <父编号>
- --mainline <父编号>
-
通常您无法拣选合并提交,因为您不知道合并的哪一边应该被视为主线。此选项指定主线的父编号(从1开始),并允许 cherry-pick 相对于指定的父提交重放更改。
- -n
- --no-commit
-
通常该命令会自动创建一系列提交。此标志将拣选每个指定提交所需的更改应用到您的工作树和索引中,而不进行任何提交。此外,使用此选项时,您的索引不必与 HEAD 提交匹配。拣选是针对您索引的起始状态进行的。
当您连续拣选多个提交的效果到您的索引中时,这很有用。
- -s
- --signoff
-
在提交消息末尾添加一个
Signed-off-by
尾部信息。有关更多信息,请参阅 git-commit[1] 中的 signoff 选项。 - -S[<密钥ID>]
- --gpg-sign[=<密钥ID>]
- --no-gpg-sign
-
GPG 签署提交。
keyid
参数是可选的,默认为提交者身份;如果指定,它必须紧贴选项,中间不能有空格。--no-gpg-sign
对于抵消commit.gpgSign
配置变量和先前的--gpg-sign
都很有用。 - --ff
-
如果当前 HEAD 与被拣选提交的父提交相同,则将执行快进到此提交的操作。
- --allow-empty
-
默认情况下,拣选空提交会失败,表示需要显式调用
git
commit
--allow-empty
。此选项会覆盖该行为,允许在拣选中自动保留空提交。请注意,当 "--ff" 生效时,满足“快进”要求的空提交即使没有此选项也会被保留。另请注意,使用此选项仅保留最初为空的提交(即,提交记录的树与其父提交相同)。由于先前提交而变为空的提交将导致拣选失败。要强制包含这些提交,请使用--empty=keep
。 - --allow-empty-message
-
默认情况下,拣选带有空消息的提交会失败。此选项会覆盖该行为,允许拣选带有空消息的提交。
- --empty=(drop|keep|stop)
-
如何处理与当前历史中已存在的更改重复的被拣选提交。
请注意,
--empty=drop
和--empty=stop
仅指定如何处理最初不为空,但由于先前提交而变为空的提交。最初为空的提交仍将导致拣选失败,除非指定了--empty=keep
或--allow-empty
中的一个。 - --keep-redundant-commits
-
已弃用的
--empty=keep
同义词。 - --strategy=<策略>
-
使用给定的合并策略。只能使用一次。有关详细信息,请参阅 git-merge[1] 中的 MERGE STRATEGIES 部分。
- -X<选项>
- --strategy-option=<选项>
-
将合并策略特定的选项传递给合并策略。有关详细信息,请参阅 git-merge[1]。
--rerere-autoupdate
--no-rerere-autoupdate
-
在 rerere 机制重用当前冲突上的已记录解决方案以更新工作树中的文件后,允许它也使用解决方案结果更新索引。
--no-rerere-autoupdate
是在通过单独的git
add
将结果提交到索引之前,仔细检查rerere
所做的工作并捕获潜在错误合并的好方法。
示例
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)
-
应用由
git
show
topic^
显示的更改。在此示例中,补丁未干净地应用,因此有关冲突的信息被写入索引和工作树,并且没有产生新的提交。 -
总结待协调的更改
-
取消拣选。换句话说,返回到拣选前的状态,保留您在工作树中进行的任何本地修改。
-
再次尝试应用
topic^
引入的更改,花费额外时间避免因不正确匹配上下文行而导致的错误。