Git应用详解第九讲：Git cherry-pick与Git rebase

前言

前情提要：Git应用详解第八讲：Git标签、别名与Git gc

这一节主要介绍git cherry-pick与git rebase的原理及使用。

一、Git cherry-pick

Git cherry-pick的作用为移植提交。比如在dev分支错误地进行了两次提交2nd和3rd，如果想要将这两次提交移植到master分支上。采用先删除再添加的方法将会很繁琐，而使用cherry-pick就能轻松实现这一需求。

首先在版本库中创建了两个分支master和dev，并模拟上述场景：

可以看到，在dev分支上进行了两次提交，在master分支上只进行了一次提交。现在想要将这两次提交移植到master分支上。整体分为两步：

• **第一步：**将dev分支上多余的两次提交移植到master分支上；
• **第二步：**删除dev分支上多余的两次提交；

1.第一步

git cherry-pick commit_id

首先切换到master分支，然后使用如下命令将dev分支上的两次提交移植到master分支上：

//移植2nd提交
git cherry-pick 009dd
//移植3rd提交
git cherry-pick aec8c

009dd和aec8c分别表示需要移植的提交2nd和3rd的SHA1值：

移植过程为：

• 如上图所示，执行了两次cherry-pick指令，创建了两个内容与2nd、3rd一致的提交对象50477和f05a0。所以，cherry-pick指令移植提交的实质是：先将需要移植的提交复制一份，再拼接到master分支上，简称先复制，再拼接；

• 上面按照顺序先移植了提交2nd再移植提交3rd，不会发生冲突；

• 不按顺序移植，如先移植提交3rd会发生合并冲突，需要手动解决：

通过vi test.txt查看发生合并冲突的test.txt文件：

可以发现master分支上initial commit提交中的文件test.txt直观上并不与提交3rd中的test.txt冲突，如下图所示：

但是为什么会发生合并冲突呢？原因在于三方合并原则：

如上图所示，当想要将dev中的提交E与master分支的提交B合并时，首先要找到B和E的公共父节点A，在A的基础上根据B和E进行三方合并；

了解了三方合并原则后就能解释上面发生合并冲突的原因了：

• 由于提交3rd是基于提交2nd创建的，因此3rd中保留了2rd中对文件的操作记录；

• 如果直接将3rd拼接到initial commit后面，就会失去提交2nd的记录；

• 由此提交3rd就不能通过提交2nd找到公共提交节点init，这就会导致合并失败；

所以，无论内容是否冲突，合并过程都会出现冲突：

**解决方法：**手动合并三步曲：

• 首先，选择要保留的内容，解决冲突：

• 然后，通过git add将修改信息纳入暂存区：

• 最后，通过git commit提交修改信息：

完成后查看master分支的提交历史：

可以看到解决冲突，手动合并后，成功完成了整个cherry-pick过程。并且新增的提交是手动合并时进行的提交，而不是直接复制的提交3rd：

2.第二步

此时两分支的状态为：

接下来就要删除dev分支上错误的两次提交2nd和3rd，相当于版本回退；可以使用三种方法：revert、reset和checkout，这里演示checkout和reset两种方法。

使用checkout

首先切换到dev分支，然后通过以下指令切换到提交initial commit：

//dd703是提交initial_commit的SHA1值
git checkout dd703

此时该节点处于游离状态：

然后再删除dev分支：

由于之前修改的dev分支没有与master