git-cherry-pick

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

概要
git cherry-pick [–edit] [-n] [-m父编号] [-s] [-x] [–ff]
[-S []] <提交> …
git cherry- pick-continue
git cherry-pick --quit
git cherry-pick --abort
描述
给定一个或多个现有提交，应用每个引入的更改，并记录每个提交的新提交。这要求您的工作树是干净的（HEAD提交没有任何修改）。

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

当前分支和HEAD指针停留在成功完成的最后一次提交上。

该CHERRY_PICK_HEAD裁判在设置点提交介绍了这是难以适用的变化。

在索引文件和工作树中，都会干净地应用更改的路径。

对于冲突的路径，索引文件最多记录三个版本，如git-merge（1）的“ TRUE MERGE”部分所述 。工作树文件将包含对冲突的描述，并用通常的冲突标记<<<<<<<和括起来>>>>>>>。

没有其他修改。

有关解决此类冲突的一些提示，请参见git-merge（1）。

选件
<提交> …
致力于摘樱桃。有关拼写提交方式的更完整列表，请参见 gitrevisions（7）。可以传递一组提交，但默认情况下不会进行遍历，就像–no-walk指定了该选项一样，请参见 git-rev-list（1）。请注意，指定范围会将所有 …参数提供给一个修订版本（请参阅后面的使用maint master…next的示例）。

-e

• 编辑
  使用此选项，git cherry-pick将允许您在提交之前编辑提交消息。

-X
在记录提交时，请在原始提交消息后添加一行``（从提交中提取樱桃…）’’，以表明此更改是从哪个提交中挑选出来的。这仅适用于没有冲突的樱桃采摘。如果您是从私人分支中挑选樱桃，请不要使用此选项，因为该信息对收件人毫无用处。另一方面，如果您在两个公开可见的分支之间进行挑剔（例如，将修补程序向后移植到维护分支以从开发分支中发布较旧的版本），则添加此信息可能会很有用。

-r
过去，该命令默认执行-x 上述操作，并且-r被禁用。现在默认为不操作，-x因此此选项为无操作。

-m父编号
–mainline父编号
通常，您无法选择合并，因为您不知道合并的哪一侧应被视为主线。此选项指定主线的父代号（从1开始），并允许cherry-pick重播相对于指定父代的更改。

-n
-不提交
通常，该命令会自动创建一系列提交。该标志将必要的更改应用到选择每个命名提交的工作树和索引中，而不进行任何提交。此外，使用此选项时，索引不必与HEAD提交匹配。对索引的开始状态进行了选择。

当连续挑选多个对索引的提交产生影响时，这很有用。

-s

• 登出
  在提交消息的末尾添加“按行签名”行。有关更多信息，请参见git-commit（1）中的signoff选项。

-S []
–gpg-sign [= ]
GPG签名提交。该keyid参数是可选的，默认为提交者身份。如果指定，则必须将其固定在选项中，且不能留空格。

–ff
如果当前HEAD与Cherry-pick提交的提交的父级相同，则将快速执行此提交。

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

-允许空消息
默认情况下，挑选带有空消息的提交将失败。此选项将覆盖该行为，从而允许选择带有空消息的提交。

–keep-redundant-commits
如果被挑选的提交与当前历史记录中已有的提交重复，则它将变为空。默认情况下，这些多余的提交导致cherry-pick停止，因此用户可以检查该提交。此选项将覆盖该行为并创建一个空的提交对象。暗示–allow-empty。

–strategy = <策略>
使用给定的合并策略。只能使用一次。有关详细信息，请参见git-merge（1）中的“合并策略”部分。

-X <选项>
–strategy-option = <选项>
将特定于合并策略的选项传递到合并策略。有关详细信息，请参见git-merge（1）。

音序器子命令

• 继续
  使用.git / sequencer中的信息继续进行中的操作 。在解决失败的樱桃选择或还原中的冲突后，可用于继续操作。

• 退出
  忘记当前正在进行的操作。失败后，可以用来清除音序器的状态。

-中止
取消操作并返回到先序状态。

例子
git cherry-pick master
在master分支的顶端应用由提交引入的更改，并使用此更改创建一个新的提交。

git cherry-pick …master
git cherry-pick ^HEAD master
应用由master始祖而不是HEAD始祖的所有commit引入的更改来生成新的commit。

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。否则，将下一个而不是HEAD中的那些提交所引入的更改应用于当前分支，为每个新更改创建一个新提交。

git rev-list --reverse master – README | git cherry-pick -n --stdin
将涉及README的master分支上的所有提交所引入的更改应用于工作树和索引，以便可以检查结果并将其放入单个新提交（如果适用）。

以下序列尝试向后移植修补程序，由于修补程序所应用的代码已更改太多而失败，然后再次尝试，这一次要更加注意匹配上下文行。

$ 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。换句话说，返回到选取前的状态，保留您在工作树中进行的所有本地修改。

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