Git cherry-pick详解-Toy模板网

这篇具有很好参考价值的文章主要介绍了Git cherry-pick详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

此文在阅读前需要有一定的git命令基础，若基础尚未掌握，建议先阅读这篇文章Git命令播报详版

对于多分支的代码库，将代码从一个分支引入到另一个分支是常见需求。

这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并（git merge）。另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 cherry-pick。

cherrypick 多个提交,GIT,git,前端

基本用法

git cherry-pick 命令的作用，就是将指定的提交（commit）应用于其他分支。

git cherry-pick <commitHash>

上面命令就会将指定的提交commitHash，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样。

举例来说，代码仓库有master和feature两个分支。

    a - b - c - d   Master
         \
           e - f - g Feature

现在将提交f应用到master分支。

# 切换到 master 分支
git checkout master

# cherry-pick 操作
git cherry-pick f

上面的操作完成以后，代码库就变成了下面的样子。

    a - b - c - d - f   Master
         \
           e - f - g Feature

从上面可以看到，master分支的末尾增加了一个提交f。

git cherry-pick命令的参数，不一定是提交的哈希值，分支名也是可以的，表示引入该分支的最新提交。

git cherry-pick feature

上面代码表示将feature分支的最近一次提交，引入到当前分支。

引入多个提交

cherry-pick 支持一次引入多个提交。

git cherry-pick <HashA> <HashB>

上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。

如果想要引入一系列的连续提交，可以使用下面的简便语法。

git cherry-pick A..B

上面的命令可以引入从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。

注意，使用上面的命令，提交 A 将不会包含在 cherry-pick 中。

代码冲突解决

如果操作过程中发生代码冲突，cherry-pick 会停下来，让用户决定如何继续操作。

--continue

用户解决代码冲突后。第一步将修改的文件重新加入暂存区（git add .），第二步使用下面的命令，让 cherry-pick 过程继续执行。
```
git cherry-pick --continue
```
或者第二步使用命令git commit进行手动提交。
--abort

发生代码冲突后，放弃合并，当前分支恢复到cherry-pick 操作前的状态，没有改变。
--quit

代码冲突后，退出 cherry-pick，但是不回到操作前的样子，当前分支中未冲突的内容状态将为modified。
--skip
则会将引起冲突的commits丢弃掉（慎用！！）

引入分支所有提交

git cherry-pick ..<branchname>
git cherry-pick ^HEAD <branchname>

Apply the changes introduced by all commits that are ancestors of master but not of HEAD to produce new commits.

翻译过来就是：

应用作为主提交祖先而不是HEAD祖先的所有提交引入的更改来生成新的提交。

晦涩难懂…。

我个人理解是，将需要合并的分支的本身的所有commit都引入到当前分支上，形成新的commitHash。不包含该分支创建时及之前的commit。

说了这么多，都不如来个例子。

查看当前分支情况

git branch

输出：
  dev
* master

可以看到当前总共有dev和master两个分支。当前检出的为master分支。

获取git log

git log --all --oneline --graph

输出：
* 190f801 (HEAD -> master, origin/master, origin/HEAD) dev change5
* 0a71a6f dev change4
| * 2517b59 (origin/dev, dev) dev change10
| * 9ccf435 dev change9
| * c8a29d9 dev change8
| * b1b3412 dev change7
| * d42d188 dev change6
| * f48f86c dev change5
| * 4d8d588 dev change4
| * 79da3ff dev change3
| * 7c8f4d5 dev change2
| * 57aaac6 dev change1
|/
* 6347c46 Initial commit

可以看到dev有10个change行为提交。

执行cherry-pick命令

git cherry-pick ..dev

git log --all --oneline --graph

输出：
* ccd075b (HEAD -> master, origin/master, origin/HEAD) dev change10
* a63fe03 dev change9
* 306f58f dev change8
* a020794 dev change7
* 6b3e7e4 dev change6
* f17a761 dev change5
* 16f37ac dev change4
* f72518c dev change3
* f97ccf7 dev change2
* f2d5f7e dev change1
* 190f801 dev change5
* 0a71a6f dev change4
| * 2517b59 (origin/dev, dev) dev change10
| * 9ccf435 dev change9
| * c8a29d9 dev change8
| * b1b3412 dev change7
| * d42d188 dev change6
| * f48f86c dev change5
| * 4d8d588 dev change4
| * 79da3ff dev change3
| * 7c8f4d5 dev change2
| * 57aaac6 dev change1
|/
* 6347c46 Initial commit

可以看到，dev分支上，从change1至change10的commit，均引入到master分支上，形成新的commitHash。而dev分支创建之前的commit，即Initial commit没有引入，这是它们共同的祖先节点。

引入另一个代码库提交

cherry-pick 也支持引入另一个代码库的提交，方法是先将该库加为远程仓库。

git remote add target gitUrl

上面命令添加了一个远程仓库target。

然后，将远程代码抓取到本地。

git fetch target

上面命令将远程代码仓库抓取到本地。

接着，检查一下要从远程仓库引入的提交，获取它的哈希值。

git log target/master --oneline

最后，使用git cherry-pick命令引入提交。

git cherry-pick <commitHash>

常用配置

-e，--edit

打开外部编辑器，编辑提交信息。

如果想要在cherr-pick时重新编辑提交信息，则使用git cherry-pick <commitHash> -e命令。
-n，--no-commit

如果不想cherry-pick自动进行提交，则加参数-n即可。引入的文件内容将放在暂存区，不产生新的commit。
-x

在提交信息的末尾追加一行(cherry picked from commit …)，方便以后查到这个提交是如何产生的。
-s，--signoff

在提交信息的末尾追加一行操作者的签名，表示是谁进行了这个操作。
-m parent-number，--mainline parent-number

如果原始提交是一个合并节点，来自于两个分支的合并，那么 cherry-pick 默认将失败，因为它不知道应该采用哪个分支的代码变动。

-m 配置项告诉 Git，应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数，代表原始提交的父分支编号。
```
git cherry-pick -m 1 <commitHash>
```
上面命令表示，cherry-pick 采用提交commitHash来自编号1的父分支的变动。

一般来说，1号父分支是作为变动来源的分支，2号父分支是接受变动的分支。

常见问题

The previous cherry-pick is now empty, possibly due to conflict resolution.

原因:

在cherry-pick时出现冲突，解决冲突后本地分支中内容和cherry-pick之前相比没有改变，因此当在以后的步骤中继续git cherry-pick或执行其他命令时，由于此时还处于上次cherry-pick进程中，就会提示该信息，表示可能是由于解决冲突造成上一次cherry-pick内容是空的。

解决方案:
1. 执行git cherry-pick --abort取消上次操作。
2. 执行git commit --allow-empty,表示允许空提交。此步骤极不推荐，极可能会造成git可视化工具显示历史提交记录出现问题。文章来源地址https://www.toymoban.com/news/detail-525246.html