对于多分支的代码库,将代码从一个分支转移到另一个分支是常见需求。
这时分两种情况。一种情况是,你需要另一个分支的所有代码变动,那么就采用合并git merge。另一种情况是,你只需要部分代码变动(某几个提交),这时可以采用 Cherry pick。
cherry-pick命令的作用
git cherry-pick命令的作用,就是将指定的提交commit应用于其他分支。例如git cherry-pick <commitHash>
命令就会将指定的提交commitHash,应用于当前分支。这会在当前分支产生一个新的提交,当然它们的哈希值会不一样。
我们用图片举例,如下图所示:
现在我如果只想将e应用到master分支上,这时候我们就不可能直接合并分支了,所以用cherrt-pick命令。
首先使用git switch master
切换到主分支,然后git cherry-pick <commitHash>
。操作完成以后,代码库就变成了下面的样子。
从上面可以看到,master分支的末尾增加了一个提交e。
git cherry-pick命令的参数,不一定是提交的哈希值,分支名也是可以的,表示转移该分支的最新提交。
git cherry-pick dev
上面代码表示将dev分支的最近一次提交,转移到当前分支。
cherry-pick转移多个提交
git cherry-pick <HashA> <HashB>
上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。
转换一系列连续提交
git cherry-pick A..B
上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置:提交 A 必须早于提交 B,否则命令将失败,但不会报错。注意,使用上面的命令,提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A,可以使用下面的语法。
git cherry-pick A^..B
git cherry-pick命令的常用配置项
-e,–edit
打开外部编辑器,编辑提交信息。
-n,–no-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号父分支是作为变动来源的分支。
Cherry-pick过程发生冲突常用命令
如果操作过程中发生代码冲突,Cherry pick 会停下来,让用户决定如何继续操作。
主要有以下几个
1、–continue
用户解决代码冲突后,第一步将修改的文件重新加入暂存区(git add .),第二步使用下面的命令,让 Cherry pick 过程继续执行。
git cherry-pick --continue
2、 --skip
跳过这个补丁
3、–abort
发生代码冲突后,放弃合并,回到操作前的样子。
4、–quit
发生代码冲突后,退出 cherry pick,但是不回到操作前的样子。
cherry-pick转移其它代码库的提交
cherry-pick 也支持转移另一个代码库的提交,方法是先将该库加为远程仓库。
首先使用git remote add target git://gitUrl
添加一个远程仓库target。然后通过git fetch target
,将远程代码抓取到本地。
接着,检查一下要从远程仓库转移的提交,获取它的哈希值git log target/master
。最后,使用git cherry-pick命令转移提交,命令如下:
git cherry-pick <commitHash>