git cherry-pick合并某个commit

在一般的项目开发过程中，我们一般在开发分支 (develop) 上提交，等项目开发完成后我们在使用 merge 命令合并到主分支 (master) 上。

但是可能会出现这样的一种情况在 develop 的开发过程中项目希望提前使用到 develop 分支上的一个新功能，而不想把 develop 还没开发完成的其他功能一起提交上线，那么这样的情况我们就需要使用到 cherry-pick 命令了。

简述展开目录

cherry-pick 这个命令和 merge 很类似，但是 cherry-pick 操作的对象是 commit，就是对已经存在的 commit 进行再次提交。

使用方式也很简单：

git cherry-pick <commit id>

commitid 我们可以使用 git log 命令来查看到。

实践展开目录

简单介绍一下提交流程：

首先我们切换到 develop 分支上，然后我们新增 3 个提交

git checkout develop
git commit -m "add 内存配置"
git commit -m "add 硬盘配置"
git commit -m "add 显卡配置"

提交日志如下

接着我们切换到 master 分支上，再次查询下日志

我们现在要做的就是把 add内存配置(0321b70) 和 add 硬盘配置(0f16d73) 合并到 master 分支上，多余的那个 add 显卡配置(1e1aa1f) 我们模拟开发尚未完成的功能，先不合并。

{ maxrnb } master » git cherry-pick 0321b70 0f16d73                                 
[master 9ae7418] add 内存配置
 Date: Mon May 11 10:00:29 2020 +0800
 1 file changed, 2 insertions(+), 1 deletion(-)
[master fbdfe5d] add 硬盘配置
 Date: Mon May 11 10:01:04 2020 +0800
 1 file changed, 2 insertions(+), 1 deletion(-)
{ maxrnb } master »

可以看到使用 cherry-pick 的合并是在 master 分支上新生成了一个 commit，对应的 commitid 分别为 9ae7418、fbdfe5d，并不是我们平常使用的 Fast-forward 合并模式。我们从 log 里也可以很清楚的看到

扩展展开目录

刚刚是一个或者两个提交 cherry-pick 到 master 分支，但如果有 100 个 commit 要合并到 master 分支呢？总不能这样一个个操作吧？cherry-pick 还提供了一个方便合并区间的方式。

git cherry-pick commit1..commit100

但是要注意，这是一个左开右闭的操作，也就是说，commit1 不会被合并到 master 分支，而 commit100 则会。

刚刚上面也说了，cherry-pick 每拣选一个 commit 就会提交一次生成一个新的 commit。如果我们想让每个 commit 拣选后暂缓提交，等到所有 commit 都拣选完成后，自己手动 commit，应该怎么办呢？可以采用 -n 选项来操作。

这个时候，我们查看 log 的话发现 log 图谱中并没有出现新的 commit，所以我们继续合并，最后手动执行 git commit -m "合并添加内存、添加硬盘提交"

最后，log 图谱如下。可以很清楚看到虽然我们抽取了 2 次 commit 来合并，但是最终在 master 上只产生了一个新的 commit，对应着图谱中的 f24a43f。

问题展开目录

有的人 (比如我) 可能会有这样的操作，cherry-pick 后面跟一系列 commitid 最后的一个。按照上面的列子我执行

git cherry-pick 0f16d73 会怎么样？

冲突内容如下

<<<<<<< HEAD
CPU: i5-7200U
=======
CPU: i5-7200U
Merory: 芝奇16G x 2
DIsk: 三星970Evo Pro
>>>>>>> 0f16d73... add 硬盘配置

这样操作的话会出现冲突，但是同样可以通过和解决普通冲突一样来操作。不过还是建议通过 cherry-pick 后面跟一个或多个 commitid 来操作规范。

总结展开目录

cherry-pick 这个命令我个人平时工作中使用到的情况还是比较少的，使用的更多的依然是 merge。但是这 cherry-pick 有更高的灵活性及更强大的自定义性。

cherry-pick 合并提交的时候是生成了新的 commitid 并不是 Fast-forward 合并模式，这点需要注意。

题图引用： https://medium.com/faun/awesome-git-technique-for-partial-merge-7d64a7e62440
文章部分参考： https://zhuanlan.zhihu.com/p/58962086

Catalog