设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
补丁
调试
电子邮件
外部系统
服务器管理
指南
管理
底层命令
- 2.45.1 → 2.49.0 无更改
-
2.45.0
2024-04-29
- 2.39.4 → 2.44.3 无更改
-
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]的“TRUE MERGE”部分所述。 工作树文件将包含由常用冲突标记
<<<<<<<
和>>>>>>>
括起来的冲突描述。 -
未进行其他修改。
有关解决此类冲突的一些提示,请参见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 的提交,这些提交与当前历史记录中已有的更改是冗余的。
请注意,
--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
所做的工作并捕获潜在的错误合并。
示例
-
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^
将显示的更改。 在此示例中,补丁未干净地应用,因此有关冲突的信息将写入索引和工作树,并且不会产生新的提交。 -
总结要协调的更改
-
取消 cherry-pick。 换句话说,返回到 cherry-pick 之前的状态,保留您在工作树中所做的任何本地修改。
-
尝试再次应用
topic^
引入的更改,花费更多时间以避免基于错误匹配上下文行的错误。
GIT
属于 git[1] 套件的一部分