Git 操作--代码分支管理命令--git cherry-pick

git-cherry-pick - 将一些现有提交引入的更改 应用到当前的代码上

Draft 持续更新中……

概要

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

描述

根据现有的一个或者多个提交，应用所有这些提交里面的每一个改动，并形成新的提交(Optional)，不过需要你当前的工作区是干净的，没有任何修改。

当出现不清楚如何应用更改发生冲突时，会发生以下情况：

1. 当前分支和HEAD指针停留在最后一次成功的提交。
2. CHERRY_PICK_HEAD 则指向因不清楚如何应用更改而引起冲突的提交。
3. 能够无冲突应用的变更的路径会更新在索引文件和自己本地的工作树中。
4. 对于冲突的变更路径，索引文件最多记录三个版本信息，分别包含：
   Merged：文件无冲突自动merged的文件版本信息，
   目标提交的：来源于要cherry-pick的提交的改动版本信息，包含在<<<<<<< 和 =======中
   本地当前的：本地当前的改动版本信息 ======= 和 >>>>>>>.
5. 没有进行其他修改。

选项

• 
  要cherry pick的提交，即要应用的更改的提交。
• -e / --edit
  使用此选项，git cherry-pick的时候将允许您在提交之前编辑commit message。
• --cleanup=
  此选项确定提交消息在传递到提交机制之前将如何清理。有关详细信息，请参阅https://git-scm.com/docs/git-cherry-pick/en and https://git-scm.com/docs/git-commit
• -x
  记录提交时，在原始提交消息中附加一行“(cherry picked from commit … )”，以指示此更改是从哪个提交中挑选出来的。这仅适用于没有冲突的 cherry picks。如果您是从您的私人分支机构挑选的，请不要使用此选项，因为该信息对收件人无用。另一方面，如果您在两个公开可见的分支之间进行挑选（例如，从开发分支向后移植旧版本的维护分支的修复），添加此信息可能很有用。
• -r
  它曾经是命令默认执行-x 上述操作，并且-r将其禁用。现在默认不-x这样做，这个选项是一个空操作。
• -m / --mainline
  通常你不能挑选合并，因为你不知道合并的哪一边应该被认为是主线。此选项指定主线的父编号（从 1 开始），并允许 cherry-pick 重播相对于指定父级的更改。
• -n / --no-commit
  通常该命令会自动创建一系列提交。此标志应用必要的更改以挑选每个命名提交到您的工作树和索引，而不进行任何提交。此外，使用此选项时，您的索引不必与 HEAD 提交匹配。cherry-pick 是针对索引的开始状态完成的。
  当连续挑选多个提交对索引产生影响时，这很有用。
• -s / --signoff
  Signed-off-by在提交消息的末尾添加一个预告片。有关更多信息，请参阅git-commit [1]中的签核选项。
• --ff
  如果当前 HEAD 与 cherry-pick 提交的父级相同，则将执行快进到此提交。
• --allow-empty
git commit --allow-empty默认情况下，cherry-picking 空提交将失败，表明需要显式调用。此选项会覆盖该行为，允许在 cherry-pick 中自动保留空提交。请注意，当“–ff”生效时，即使没有此选项，也将保留满足“快进”要求的空提交。另请注意，使用此选项仅保留最初为空的提交（即提交记录与其父级相同的树）。由于先前的提交而变为空的提交将被删除。要强制包含这些提交，请使用--keep-redundant-commits.
• --allow-empty-message
  默认情况下，cherry-picking 带有空消息的提交将失败。此选项会覆盖该行为，允许挑选带有空消息的提交。
• --keep-redundant-commits
  如果被挑选的提交复制了当前历史记录中已经存在的提交，它将变为空。默认情况下，这些冗余提交会导致cherry-pick停止，以便用户可以检查提交。此选项会覆盖该行为并创建一个空的提交对象。暗示–allow-empty。
• --strategy=
  使用给定的合并策略。应该只使用一次。有关详细信息，请参阅git-merge [1]中的 MERGE STRATEGIES 部分 。
• -x / --strategy-option= 将特定于合并策略的选项传递给合并策略。有关详细信息，请参阅git-merge [1]。
• --rerere-autoupdate / --no-rerere-autoupdate
  在 rerere 机制重新使用记录的当前冲突的解决方案来更新工作树中的文件后，允许它也使用解决方案的结果更新索引。 --no-rerere-autoupdate是一种很好的方法rerere，可以在使用单独的git add.

后续子命令

• --continue
  使用 中的信息继续正在进行的操作 .git/sequencer。可用于在解决失败的 cherry-pick 或恢复中的冲突后继续。
• --skip
  跳过当前提交并继续序列的其余部分。
• --quit
  忘记当前正在进行的操作。可用于在 cherry-pick 或恢复失败后清除音序器状态。
• --abort
  取消操作，返回到前序状态。

举例

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 或其任何祖先。请注意，后者并不意味着andmaint之间的所有内容；具体来说， 如果包含在.masternextmaintmaster

git cherry-pick master~4 master~2

应用由 master 指向的倒数第五次和倒数第三次提交引入的更改，并使用这些更改创建 2 个新提交。

git cherry-pick -n master~1 next

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

git cherry-pick --ff ..next

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

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

将接触 README 的 master 分支上的所有提交引入的更改应用到工作树和索引，因此可以检查结果并在合适的情况下将其放入单个新提交中。

以下序列尝试向后移植补丁，由于应用补丁的代码更改太多而退出，然后再次尝试，这次更加注意匹配上下文行。

$ git cherry-pick 主题^              (1) 
$ git diff                           (2) 
$ git cherry-pick --abort            (3) 
$ git cherry-pick -Xpatience 主题^   (4)

1. 应用将显示的更改git show topic^。在此示例中，补丁没有完全应用，因此有关冲突的信息被写入索引和工作树并且没有新的提交结果。
2. 总结要协调的变化
3. 取消cherry pick。换句话说，返回到 pre-cherry-pick 状态，保留您在工作树中所做的任何本地修改。
4. 尝试再次应用引入的更改topic^，花费额外的时间来避免基于不正确匹配上下文行的错误。

https://git-scm.com/docs/git-cherry-pick/en
https://zhuanlan.zhihu.com/p/521727201