AhuntSun

# 第九讲：Git cherry-pick与Git rebase

# 前言

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

# 一、Git cherry-pick

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

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

image-20200418213440673

可以看到，在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
1
2
3
4

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

image-20200418215229274

移植过程为：

image-20200418220353735

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

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

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

image-20200418220823727

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

image-20200408123432173

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

image-20200408123754034

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

image-20200408143344853

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

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

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

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

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

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

image-20200418222100291

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

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

image-20200408133308462

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

image-20200408133412891

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

image-20200418222349351

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

image-20200418222512780

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

image-20200418222844236

# 2.第二步

此时两分支的状态为：

image-20200418223143850

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

# 使用checkout

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

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

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

image-20200418223451519

然后再删除dev分支：

image-20200418223548734

由于之前修改的dev分支没有与master进行合并，所以删除时需要使用参数-D强制删除。

删除后，剩下master分支与游离提交。此时再通过以下指令将游离的节点设置为dev分支即可：

git checkout -b dev
1

image-20200418223939367

由此通过"偷天换日"的方式使dev分支回到了错误提交前的状态；

# 使用reset

由于使用checkout只是移动了HEAD指针，没移动dev分支指针，所以会出现游离提交节点；而reset会同步移动HEAD和dev分支指针，不会造成这样的问题。所以这里使用reset进行版本回退会简单很多：

git reset --hard dd703
1

image-20200418224610750

# 二、git rebase简介

首先，rebase有两个意思：变基、衍合，即变换分支的参考基点。默认情况下，分支会以分支上的第一次提交作为基点，如下图所示master分支默认以提交1st作为基点：

image-20200409151236167

如果以提交4th作为master分支的基点，master分支就会变为：

image-20200409151428243

这个变化基点的过程就称之为变基（rebase）；

rebase与merge十分相似，不过二者的工作方式有着显著的差异。比如：将A和B两分支进行合并：

  • 在A分支上执行git merge B，表示的是将B分支合并到A分支上；
  • 而在A分支上执行git rebase B，则表示将A分支通过变基合并到B分支上；

# 三、merge与rebase

# 1.采用merge合并分支

image-20200408232708342

现在有两个分支origin和mywork，如果想要将origin分支合并到mywork分支上。根据三方合并原则，需要在c4、c6和它们的公共父提交节点c2的基础上进行合并：

image-20200408232523880

合并后产生一次新的提交c7，该提交有两个父节点c4和c6。具体的合并方式为：如果没有冲突git就会自动采用Fast-forward方式进行合并，有冲突就解决冲突再进行手动合并。

# 2.采用rebase合并分支

由于是mywork分支需要变基合并到origin分支上，所以首先切换到mywork分支（注意这里与采用merge方法时所在的分支相反）：

git checkout mywork
1

再进行合并：

git rebase origin
1

合并后的结果为：

image-20200408232225944

**注意：**被合并的分支origin保持不动，而合并它的分支mywork将自己的提交作为补丁（patch）一个个应用（applying）到分支origin指向的提交后面；

在这个过程中git会自动创建c5'和c6'。原来的c5和c6就没用了，会被git gc回收。合并后分支mywork的提交记录变成了一条直线：

image-20200408231936193

也就是说：rebase会将被合并分支（mywork）上的提交应用到合并分支（origin）上，并且修改被合并分支（mywork）的提交记录。

# 四、rebase原理分析

如图所示，master和dev分支都以提交节点A为基准点：

image-20200418232253571

如果dev分支想要变换A这个基准点，那么：

**第一步：**切换到dev分支上；

**第二步：**执行git rebase master，过程如下；

上述命令中rebase参数后面指定的就是变更后的基准点：

  • 如果是分支，如master，基准点为该分支的最新提交节点，也就是C；
  • 如果是一个commit_id，基准点为该commit_id对应的提交节点；

# 1.基准点为分支

沿用以上模型：

image-20200418232806243

  • 首先，将dev分支上除了基准点A外的所有节点复制一份，即D'和E'，作为补丁备用，并将分支dev指向新基准点C：

image-20200418232419176

  • 然后，按原来dev上的节点顺序（D->E）将补丁应用（Patch Applying）到新基准点C后面，并同时改变分支dev指向：

追加补丁D'：

image-20200418232650653

每次向新基准点应用补丁时，都会出现三个选项：

image-20200418232951097

# git rebase --continue

该选项表示：解决了合并冲突后，继续应用剩余补丁E'：

image-20200418233223765

# git rebase --skip

该选项表示：跳过当前补丁，继续应用下一个补丁：

image-20200418233400640

如果一直执行该选项，直到应用完分支dev上的补丁，结束rebase后，两分支的状态为：

image-20200418233514562

# git rebase --abort

该选项表示：终止rebase操作，回到执行rebase指令前的状态：

image-20200418233837513

# 2.基准点为提交

# 过程详解

image-20200409184756113

如图所示，若将提交节点B作为基准点，在当前test分支上执行：

git rebase 3ccc8
1

会直接将原来的节点C和D应用到新基准点B后，相当于没有发生变化，这个变基的过程为：

  • 首先，将基准点和test分支指向改变为节点B，并将test分支上基准点往后的提交节点作为补丁：

image-20200409195531185

  • 然后，按顺序将补丁C和D应用到新基准点B后面：

image-20200409202803624

  • 最后，test分支的状态为：

image-20200409202843582

所以，直接执行git rebase 678e0不会有任何变化：

image-20200409203900098

但是，我们可以通过在rebase中添加参数-i，进入rebase交互模式，这样就能在rebase操作过程中对特定的补丁进行一系列操作；

# 实战演示

首先在test分支上进行了四次提交：

image-20200409191637780

执行以下指令将test分支的基准点变为提交节点B（678e0），并进行变基：

git rebase -i 678e0
1

执行该指令后，会进入vim编辑器：

image-20200409192056322

可以根据需要将pick参数，改变为下面代表不同作用的参数；这样就可以对节点C和D进行不同的操作了。比如：

  • pick：默认参数，表示不对提交节点进行任何操作，直接应用原提交节点。不创建新提交；
  • reword：应用复制过后的原提交节点，但是可以编辑该节点的提交信息。通过这个参数，可以修改特定提交的提交信息。会创建新的提交；
  • edit：应用复制过后的原提交节点，会在设置了该参数的补丁上停止rebase操作。待修改完该补丁后，调用git rebase --continue继续进行rebase。会创建新的提交；
  • squash：将新基点后面的全部提交节点进行合并，也就是将这里的C和D两个节点进行合并。会创建新的提交；
  • 还有其他参数这里就不一一介绍了。

这次直接使用默认的pick参数，通过:wq保存并退出vim编辑器，完成rebase操作：

image-20200409194956051

执行rebase操作前：

image-20200409191637780

可以看到当新基准点为特定提交时：

  • 在rebase的过程中使用默认参数pick，并不会像当新基准点为分支时那样创建新的提交；
  • 而一旦使用其他参数（如reword）对补丁进行了修改，就会创建新的提交；

# 五、rebase注意事项

  • 不要对master分支执行rebase，否则会引起很多的问题（master一定是远程共享的分支）；

  • 一般来说，执行rebase的分支都是自己的本地分支，千万不要在与其他人共享的远程分支上使用rebase；

    这不难理解，远程分支上的代码可能已经被其他人克隆到本地了，如果通过rebase修改了远程分支的提交历史，这样其他人每次拉取代码到本地时，就都需要进行复杂的合并。

  • 所以，本地的非master分支合并时推荐使用git rebase，其他分支的合并推荐使用git merge；

注意：git merge和git rebase的显著区别是，前者不会修改git的提交记录，而后者会！

# 六、rebase应用场合

# 1.合并分支

由于git merge采用的是三方合并的原则，没有公共提交节点就无法进行合并，此时可以采用rebase进行合并。如下图所示：

image-20200411205020369

本地master与远程master分支没有公共提交节点，无法采用git merge合并。可采用rebase进行合并：

//origin/master代表着远程master分支
git rebase origin/master
1
2

合并后本地master分支的状态为：

image-20200411205034662

# 2.修改特定提交

以下情况就适合使用rebase来解决，当回退版本并进行修改时：

比如在master分支上进行了3次提交：

image-20200419174116301

回退到第二次提交2nd，并对提交信息进行修改：

image-20200419174313522

当我们回到原来的第三次提交3rd时，会发现之前的修改并没有被保存：

image-20200419174404816

此时可以使用rebase，将提交1st作为新的提交节点（正如第四大点讲解的）。首先执行：

git rebase -i 5ab3f
1

通过添加参数-i进入交互模式，将提交2nd默认的pick参数修改为reword参数：

image-20200419174618553

保存并退出后，进入修改提交信息界面：

image-20200419174829838

保存并退出，由此完成修改：

image-20200419174935598

# 七、rebase实战

为了演示，额外创建两个分支dev和test，分别在两个分支上进行两次提交:

image-20200419150528809

它们有一个共同的父节点提交节点init，此时本地仓库的状态如下：

image-20200419154602095

  • 由于要对test分支进行变基，从而合并到dev分支上，所以需要先切换到test分支上，这与merge操作是相反的；

  • 随后在test分支上执行如下命令对该分支进行变基：

git rebase dev
1

该指令翻译过来就是：我test 分支，现在要重新定义我的基准点，即使用 dev 分支指向的提交作为我新的基准点。过程如下：

  • 首先，将test分支上的提交（补丁）tes1应用到新基准点dev2尾部，出现了合并冲突：

    image-20200419151735485

    查看状态，发现test分支变基过程中的新基准点正是dev分支指向的提交361be，即提交节点dev2：

    image-20200419152146120

如图所示，此时有三个选项：

  • 选项一：git rebase --abort：表示终止rebase操作，恢复到操作前；

  • 选项二：git rebase --skip：表示丢弃当前test分支的补丁，如果一直执行该选项，变基完成后，两分支的状态如下所示：

    image-20200419154352758

    即此时test分支与dev分支上具有相同的文件：

    image-20200419155017163

    并且test分支上的提交记录被改变为了dev分支上的提交记录：

    image-20200419153242071

    这就是一直执行选项git rebase --skip，丢弃全部test分支补丁的结果：

  • 选项三：git rebase --continue：解决冲突，手动合并后，继续变基；

    在dev分支上新增两次提交dev3和dev4：

    image-20200419153831132

    切换回test分支同样新增两次提交tes3和tes4：

    image-20200419154032932

    此时两分支的状态为：

    image-20200419184609655

    随后在test分支上执行git rebase dev，在处理test分支上的第一个补丁tes3时出现冲突：

    image-20200419155615321

    打开冲突文件test.txt，手动解决冲突：

    image-20200419155711866

    删除4、7、9行：

    image-20200419155812608

    解决冲突后，执行git add将对文件``test.txt`的修改操作纳入暂存区，标识已解决冲突：

    **注意：**这里并不需要进行一次提交，继续执行rebase操作即可；

    image-20200419160220448

    随后再执行git rebase --continue，继续处理test分支的下一个补丁（变基）：

    image-20200419160305488

    rebase结束后，查看test分支的提交记录：

    image-20200419160412284

    可以发现修改了test分支的提交历史，达到了预期的合并效果。

    并且，此时test分支上的tes3与tes4两次提交的SHA1值与执行rebase前这两次提交的SHA1值是不一样的：

    image-20200419160741986

    这也就验证了，git在rebase过程中会自动创建提交节点的结论。此时dev分支与test分支的状态如下所示：

    image-20200419161342071

    如果在dev分支上执行git merge test，采用的应当是Fast-forward方式：

    image-20200419161456806

    使用gitk可以更加直观地表示这一状态：

    image-20200419161529226

细心的你可能已经发现了，rebase与cherry-pick十分类似。只不过cherry-pick不会修改分支提交记录，而rebase会。

# 八、merge与rebase的选择

使用rebase时要遵循rebase的黄金法则：永远不要在公共分支上使用rebase。公共分支可以理解为master分支。由于rebase会重写分支提交记录，因此会给项目的回溯带来危险。以下为它与merge的区别：

  • merge是一个合并操作，使用git merge提交历史会出现分叉，显得不是那么简洁。但是，它的好处在于不会修改任何一次提交，会完整地将所有的提交都保存下来，方便回溯。并且只能合并有公共提交节点的分支；

  • rebase是没有合并操作的，它只是将当前分支所做的修改复制到了目标分支的最后一次提交上。所以可以不受三方合并原则约束，合并没有公共提交节点的分支；

    使用rebase会修改提交历史，得到的分支提交历史更加整洁。就好像写书，只会出版最终版本，之前的书稿并不会出版。但是，一定要注意不能在共享的分支上使用rebase。

二者都是很强大的分支整合命令，使用哪个由具体情境决定。

# 九、rebase、reset、revert

这三个指令的名字很像，容易混淆，下表对比了它们的用途以及区别：

指令 改变提 交历史 用途
Reset 是 把目前分支的状态设定成某个指定的Commit状态，通常适用于尚未推送的Commit
Rebase 是 不管是新增、修改、删除Commit都相当方便。可用来整理、编辑还未推送的Commit，通常也只适用于尚未推送的Commit
Revert 否 新增一个Commit来反转（取消）另一个Commit内容，原本的Commit依旧会保留在提交历史中。虽然会因此而增加Commit数，但通常比较适用于已经推送的Commit，或者不允许使用Reset或Rebase指令修改提交历史的场合

# 十、git最佳实践

学到这里就可以完全理解使用git将本地仓库文件推送到远程仓库的一般步骤了：

  • **第一步：**创建本地仓库：

    git init
    1

  • **第二步：**添加用户信息：

    git config --global user.name '张三'
git config --global user.email 'zhangsan@git.com'
    1
    2

  • **第三步：**添加远程仓库地址：

    git remote add origin https://www.github.com/example
    1

  • **第四步：**修改文件；

  • **第五步：**将工作区中的文件纳入暂存区：

    git add .
    1

  • **第六步：**将暂存区中的文件提交到版本库：

    git commit -m '注释'
    1

  • **第七步：**与远程仓库进行同步：

    git pull --rebase origin master
    1

  • **第八步：**建立本地分支与远程分支的联系，并进行推送：

    git push -u origin master
    1
最后更新于: 2020年6月13日星期六晚上7点32分

← 第十讲：Git子库：submodule与subtree →