命名

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_HEADRef设定点在提交该介绍，很难应用更改。

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^再次引入的更改，花费额外的时间避免基于错误匹配的上下文行的错误。