## 命名

git-cherry-pick - 应用一些现有提交引入的更改

## 概要

    git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]                  [-S[<keyid>]] <commit>…

    git cherry-pick --continuegit cherry-pick --quit

    git cherry-pick --abort

## 描述

给定一个或多个现有的提交，应用每个引入的更改，为每个提交一个新的提交。这要求你的工作树是干净的（不需要修改 HEAD 提交）。

如果不清楚如何应用更改，则会发生以下情况：

1. 当前分支和`HEAD`指针停留在最后一次成功提交。

2. 该`CHERRY_PICK_HEAD`Ref设定点在提交该介绍，很难应用更改。

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`可让您在提交之前编辑提交消息。

-x

当记录提交时，在原始提交消息中附加一行说“（从挑选中提取的樱桃...）”，以表明该更改是从哪个提交中挑选出来的。这只对樱桃选择没有冲突。如果您正在从您的私人分支进行挑选，请勿使用此选项，因为这些信息对收件人无用。另一方面，如果您在两个公开可见的分支之间进行选择（例如，向开发分支中的旧版本的维护分支返回修复），添加此信息可能很有用。

-r

它曾经是命令默认做`-x`了上面描述，并且`-r`是禁用它。现在默认不这样做`-x`，这个选项是没有操作的。

-m parent-number --mainline parent-number

通常你不能选择合并，因为你不知道合并的哪一边应该被认为是主线。此选项指定主线路的父代号码（从1开始），并允许 cherry-pick 重播相对于指定的父代的更改。

-n --no-commit

通常，该命令会自动创建一系列提交。此标志应用所需的更改，以便将每个命名提交挑选到工作树和索引，而不进行任何提交。此外，使用此选项时，您的索引不必与 HEAD 提交匹配。cherry-pick 是根据索引的开始状态完成的。

当在一行中选择多个“索引”效果到索引时，这非常有用。

-s --signoff

在提交消息的末尾添加 Signed-off-by 行。有关更多信息，请参阅 git-commit [1] 中的 signoff 选项。

-S<keyid> --gpg-sign=<keyid>

GPG 标志提交。该`keyid`参数是可选的，并且默认为提交者身份; 如果指定，它必须粘贴到选项没有空格。

--ff

如果当前的 HEAD 与 cherry-pick 的提交的父对象相同，则将执行快速转发此提交。

--allow-empty

默认情况下，cherry-pick 一个空的提交将失败，表明需要显式调用`git commit --allow-empty`。该选项会覆盖该行为，允许空提交在 cherry-pick 中自动保留。请注意，当“--ff”有效时，即使没有此选项，也会保留符合“快进”要求的空提交。还要注意，使用这个选项只保留最初为空的提交（即提交记录与其父代相同的树）。由于先前的提交而提交的提交被删除。强制包含这些提交使用`--keep-redundant-commits`。

--allow-empty-message

默认情况下，用空信息挑选提交将失败。该选项将覆盖该行为，允许提交空消息提交。

--keep-redundant-commits

如果提交 cherry-pick 复制了当前历史记录中的提交，它将变为空。默认情况下，这些冗余提交会导致`cherry-pick`停止，以便用户可以检查提交。该选项将覆盖该行为并创建一个空的提交对象。意味着`--allow-empty`。

--strategy=<strategy>

使用给定的合并策略。只能使用一次。有关详细信息，请参阅 git-merge [1] 中的 MERGE STRATEGIES 部分。

-X<option> --strategy-option=<option>

将合并策略特定选项传递给合并策略。有关详细信息，请参阅 git-merge [1] 。

## Sequencer 子命令

--continue

使用中的信息继续正在进行的操作`.git/sequencer`。可以在解决失败的 cherry-pick 或恢复中的冲突后继续使用。

--quit

忘记当前正在进行的操作。在 cherry-pick 或恢复失败后可用于清除定序器状态。

--abort

取消操作并返回到预序列状态。

## 例子

`git cherry-pick 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 指向的第五次和第三次提交所引入的更改，并创建两个新提交并进行这些更改。

`git cherry-pick -n master~1 next`

向工作树和索引应用由 master 指向的第二次提交引入的更改以及 next 指向的最后一个提交的更改，但不要使用这些更改创建任何提交。

`git cherry-pick --ff ..next`

如果历史记录是线性的并且 HEAD 是下一个祖先，则更新工作树并前进 HEAD 指针以匹配下一个。否则，将那些位于 next 而不是 HEAD 的提交引入的更改应用于当前分支，为每个新更改创建一个新的提交。

`git rev-list --reverse master -- README | git cherry-pick -n --stdin`

将触及 README 的主分支上的所有提交引入的更改应用于工作树和索引，以便可以检查结果并在合适的情况下将其作为单个新提交。

以下顺序尝试回溯修补程序，因为修补程序适用的代码发生了太多变化，然后再次尝试，因此这段时间会更注意匹配上下文行。

    $ git cherry-pick topic^             (1)$ git diff                           (2)$ git reset --merge ORIG_HEAD        (3)$ git cherry-pick -Xpatience topic^  (4)

1. 应用将显示的更改`git show topic^`。在这个例子中，这个补丁并没有很好的应用，所以关于冲突的信息被写入索引和工作树，并且没有新的提交结果。

2. 总结要调和的变化

3. 取消 cherry-pick 。换句话说，返回到 cherry-pick 前的状态，保留您在工作树中进行的任何本地修改。

4. 尝试应用`topic^`再次引入的更改，花费额外的时间避免基于错误匹配的上下文行的错误。