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

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

需求场景

需求描述

项目组要做一个POC演示，部署一个POC环境，部署的代码单独拉一个分支，从下图看，以分支1为基础创建分支dev_poc，并将2、3、4的提交的代码合并到dev_poc分支上。

实现步骤

第1步：在分支1的基础上创建分支dev_poc

git checkout -b dev_poc

第2步：将4处提交的代码合并到dev_poc

git cherry-pick 1960794

Auto-merging b.txt
CONFLICT (content): Merge conflict in b.txt
error: could not apply 1960794... fix: bug1
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

# 执行后，如果文件有冲突会有如上提示，我们继续合并，根据提示执行如下操作
处理冲突
git add .
git cherry-pick --continue

第3步：将3处提交的代码合并到dev_poc

git cherry-pick 9d8d3b8 -m 1

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

-m配置项就是告诉git应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数，代表原始提交的父分支编号。

一般来说，1表示的父分支是接受变动的分支(the branch being merged into)，2表示的父分支是作为变动来源的分支(the branch being merged from)。

结合我们的现实场景，1就是dev_feature1分支，2就是fix_bug2分支

第4步：将2处提交的代码合并到dev_poc

git cherry-pick 56e2b41

这样就达到了我们预期的效果啦。

Cherry pick总结

基本用法

# 将指定的提交commitHash，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样。
git cherry-pick <commitHash>

# 转移多个提交，将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。
git cherry-pick <HashA> <HashB>

# 转移一系列的连续提交，可以转移从 A 到 B 的所有提交。
# 它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。
git cherry-pick A..B 

# 注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法。
git cherry-pick A^..B 

转移到另一个代码库

Cherry pick也支持转移另一个代码库的提交，方法是先将该库加为远程库

# 下面的命令添加一个远程仓库target
git remote add target git://gitUrl

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

# 下面的命令将远程代码仓库抓取到本地
git fetch target

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

git log target/master

最后，使用下面命令转移提交

git cherry-pick <commitHash>

参考文档：

• git cherry-pick 教程 - ruanyifeng.com/blog/2020/0…