git rebase 详解 - 技术栈

文章目录

一、重建提交历史
- [1. 功能原理](#1. 功能原理)
- [2. 使用方法](#2. 使用方法)
- [3. 使用场景：](#3. 使用场景：)
- [4. rebase VS merge](#4. rebase VS merge)
- - [4.1 异同点](#4.1 异同点)
  - [4.2 使用rebase进行合并的好处](#4.2 使用rebase进行合并的好处)
  - [4.3 小结](#4.3 小结)

git rebase，顾名思义即变基，不过这是一条多功能命令，既可以重建提交历史，还可以整合不同分支间的变更。

本文将对相关功能进行介绍。

文中的截图为使用git 练习平台创建的，不熟悉git的可以使用这个练习一下。

一、重建提交历史

该功能也即rebase的本意：变基。

1. 功能原理

当执行rebase操作时，git会从两个分支的共同祖先开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面。

2. 使用方法

git 复制代码

git rebase [基节点] 
git rebase [基节点] [待变基节点]

这里可以看到rebase后面的参数可以是两个也可以是一个，当rebase为一个参数的时候其实是省略了第二个参数，第二个参数为HEAD指针当前指向的那个节点。

3. 使用场景：

在一个新项目中，你们的代码经过多次开发终于上线了，为了便于说明，我们先假设所有的代码提交都是在主分支 main 上进行的（别问主分支为什么不叫master，GitHub改版之后的默认分支名改成main了，这里与时俱进一下），并且已经有了C0，C1，C2三个节点的提交（这里的节点名C0用以代指相关commit操作完成后得到的那个HASH值，下同）。

此时你的leader想到了一个好的功能点，并专门指派你去将这个功能开发出来。与此同时，main 分支上仍有其它小伙伴进行更新提交。

于是，过了一段时间，你们的git分支大概被整成了这样：你在你的分支上一次提交了三次：C3，C4，C5。你们的主分支在此期间更新了C6，C7，C8三个节点

现在要进行功能合并：将你开发新功能的feature分支合并到主分支上。

此时你可能会脱口而出："merge一下不就好了吗？"

的确。如果你之前几乎没用过这个命令的话，这是最自然而然的一种做法。

但是今天我们要聊的是rebase，接下来先看一下使用rebase是怎么解决的：

（1）首先切换到feature分支：

git 复制代码

git checkout feature

（2）然后执行变基操作：

git 复制代码

git rebase main
#此处我们使用了带有一个参数的命令
#如果使用带有两个参数的命令则是：git rebase main feature

操作后的结果是这样的：

（其实我觉得这个图画的有点问题，合并后的分支仍然是feature，但是原来的main分支是没有变的，想要合并还需在main分支上执行git merge操作）

根据前文所描述的操作原理：

首先，它会找出当前所在分支和变基分支的共同Parent，即C2；
然后，将当前分支中C2之后节点的快照暂存，即：C3，C4，C5；
最后，将刚刚提取的修改应用到基分支main的最新提交的后面，便得到了上图。

如果采用merge呢？

git 复制代码

git checkout main
git merge feature

操作结果如下：

可以看到：在主分支main后面生成了一个新的节点C9（生成新节点也同时意味着这里会有一条日志：Merge XXX from XXX)。

底层的操作原理为：先将主分支的最新节点C8的快照，feature分支最新节点C5的快照与两个分支共同Parent节点C2的快照执行三路合并生成新的快照，并基于此快照生成一个连接主分支与feature分支的节点C9，最后调整main的指向。

4. rebase VS merge

4.1 异同点

首先二者都具备整合分支间变更的能力，但二者的实现手段却大不相同：git merge总是在推进提交历史，并不会影响提交的原始状态，而git rebase整合变更的方式则是对提交历史进行重写，但从结果上看，最后git rebase形成的节点C5`与git merge形成的节点C9完全相同。

4.2 使用rebase进行合并的好处

rebase不产生新节点，当然也不会产生新的commit日志，但是merge过程中会产生一条几乎"无用"的Merge日志。

rebase产生冲突并合并冲突发生在你操作git rebase时，而合并冲突这个操作是你自己进行的；但是你提交合并申请的时候一般情况下会有评审，由评审者解决冲突，开发者人多的情况下工作量可想而知。

4.3 小结

在日常的小规模项目开发中，这种差异几乎可以忽略。但是在复杂的多人协作开发场景下，随着项目迭代的不断推进和工程复杂度的不断提高，rebase往往能助力生成相对清爽的提交历史，进而方便追溯工程的演进历史和缺陷排查。

（如果使用rebase进行合并，就会呈现出比较清爽的提交日志，也不会有那么多线，而是一条直线）

接下来的明天再写，狗命要紧，先睡觉。。。