谁能解释 git cherry-pick <sha> 的作用？答案

【问题标题】：Can anyone explain what git cherry-pick <sha> does?谁能解释 git cherry-pick <sha> 的作用？
【发布时间】：2012-06-29 21:59:51
【问题描述】：

我担心的是，我在另一个本地分支中有旧的提交 [包含 abc.cpp、def.cpp]。

现在几个月后我想使用这些更改，但在我当前的分支中 abc.cpp 已升级。那么，如果我选择樱桃，它会将旧 abc.cpp 的更改整合到新 abc.cpp [最近的工作目录副本] 中吗？

【问题讨论】：

【解决方案1】：

请注意，使用git1.8.5/1.9 (Q4 2013)，git cherry-pick 现在可以轻松地从“上一个分支”中挑选：

就像“git checkout -”知道要签出和“git merge -”知道合并您之前所在的分支一样，“git cherry-pick”现在可以理解“git cherry-pick -”从之前的分支中选择。

“-”缩写对于“cherry-pick”很方便，例如“checkout”和“merge”。

“-”代表上一个分支的名称，其中一个分支名称被接受并且它不能表示任何其他东西，例如标准输入，这也有利于统一。

【讨论】：

【解决方案2】：

是的，它就是这样做的。 cherry-pick 正在将提交（或其中的一个范围）作为补丁应用到您的分支（嗯，almost as a patch）。

您可能会发生冲突（例如合并分支时），因为您的分支上发生了独立的修改。

【讨论】：

【解决方案3】：

git-cherry-pick(1) 手册页说：

给定一个或多个现有提交，分别应用更改介绍，为每个记录一个新的提交。这需要你的工作树要干净（不修改 HEAD 提交）。

简单来说，这意味着git cherry-pick 将提交从一个分支应用到另一个分支，但不会像正确合并那样保留来自另一个分支的原始历史或祖先。

将其视为应用一系列选定的补丁，而不是两个历史分支的完全合并。显然，如果您倾向于进行非常小的原子提交，那么挑选樱桃看起来就像应用一个编写良好的补丁。但是，由于您没有像合并或变基那样有共同的祖先，如果您的提交不是小而孤立的，您可能需要解决更多的冲突。

挑选樱桃是否是一个好主意在很大程度上取决于您如何构建提交。如果它不适合您，您可以随时使用 git format-patch 和 git apply 手动执行更多操作。

【讨论】：