前言
前文我们介绍过git rebase -i交互式变基的用法，它的目的就是改变提交记录；
今天我们介绍变基的另一种用法，合并分支；
rebase和merge很像，都是用来合并分支，而且合并的结果也一样；
rebase 变基这个词属于直译过来的，听起来会有点怪怪的；
虽然很怪，但是很符合实际情况，我们可以这样理解，rebase变基 就是改变基础，把本来基于快照A提交的记录整合到快照B上面；
下面我们来详细介绍下变基；
也有的地方把rebase叫做衍合，这个都不重要。
目录
-
什么是rebase
-
为什么会需要rebase
-
rebase有哪些风险
-
rebase和merge的区别
正文
1. 什么是rebase
rebase 就是把当前分支上的提交重新应用到另一个分支上，使得所有的提交整合成一条直线；
用图来看会比较直观，假设当前有两个分支topic和master：
A---B---C topic
/
D---E---F---G master
我们现在把topic的提交重新应用到master分支上，也就是变基操作，
git switch topic # 切换到 topic 分支
git rebase master # 将当前分支 topic 变基到 master 分支
那么变基之后的状态如下所示：
A'--B'--C' topic
/
D---E---F---G master
可以看到，本来topic分支的A是基于E进行修改的，变基之后，topic分支的A基于G；
最后我们再执行合并操作：
git switch master
git merge topic
这时的状态如下所示：
D---E---F---G---A'--B'--C' master，topic
可以看到，执行变基操作后，提交记录显示为一条直线；
这对于有强迫症的人来说会很舒服；
2. 为什么会需要rebase
因为rebase之后，提交记录会变成一条直线，这样我们在往远程仓库推送记录时会很整齐；
相反的，如果没有变基，只是单纯地进行合并操作，那么久而久之，提交记录就会变得很混乱；
比如我们参与了一个开源项目的维护，那么我们在自己的分支开发完成后，可以将其变基到master分支，然后再提交代码，这样别人看到的都是一条整体的提交记录线；
3. rebase有哪些风险
如果某个提交已经推到了远程仓库，那么此时对这个提交进行变基，就会很麻烦；
因为变基的本质就是改变基础：丢弃旧的提交，创建新的提交，并修改指向的基础；
下面我们用例子来看下，如下所示，是现在的提交状态：C2和C3进行合并操作，然后推到远程仓库
远程仓库的状态：
C3
/ \
C1--C2--C4 origin/master
此时小王拉了这个提交并进行了开发，提交了C5；
小王的本地状态：
C3
/ \
C1--C2--C4--C5 master
结果你又回滚了刚才的合并操作，改为变基操作：将C3变基到C2上（变基后C3和C4就不存在了），然后推到远程仓库
远程仓库的状态：
C1--C2--C3' origin/master
然后小王又拉了一次：
小王的本地状态：
C3
/ \
C1--C2--C4--C5--C3' master
此时小王在本地查看提交记录，就会发现C4和C3'的提交信息都是一致的，包括作者、日期、描述信息，此时就会给人造成一种混乱的感觉；
因为合并和变基后的结果都是一样的，只是历史记录不一样，所以这里看到的 C4合并结果 和 C3'变基结果 信息一致
而且如果小王将本地代码推到远程仓库，那么C3和C4也会被推上去；
但是此时对于远程仓库来说，C3和C4是变基过程的产物，是已经被丢弃过的，所以这里就又会造成混乱；
总的来说就是，变基只适合在本地操作，如果记录已经推到了远程仓库，那么就不能再执行变基操作；
4. rebase和merge的区别
简单一点来说，就是merge合并操作的结果会保留原有的提交记录；
而rebase变基操作的结果不会保留原有的提交记录，取而代之的是一条整齐的提交记录线；
他俩的相同点就是：结果是一致的，就是变基和合并后，代码的内容和记录信息完全一致；
总结
- 变基rebase 就是把当前分支上的提交重新应用到另一个分支上，使得所有的提交整合成一条直线；
- 之所以要用变基，就是因为变基可以使得提交记录更加整洁清晰
- 变基的风险就是如果代码已经推到了远程仓库，那么变基就会造成混乱；
- 变基和合并操作的结果都是一样的，只是过程不同：变基不会保留原有的提交记录，而合并会保留原有的提交记录
评论区