git rebase【变基】

含义：顾名思义，变更根基

作用：版本合并，使git提交记录简洁，下面有三个应用场景

版本合并【场景一】

假设你开发了4个版本，【现在处于t4版本】，想要将t2,t3,t4合并为一个版本

输入命令

git rebase -i bc0982ed7fb62cb0b65928f9fbcd7ab94985c3ce（t2版本号)  # 合并t2,t3,t4
或
git rebase -i HEAD~3  # 合并t2,t3,t4

选择如何合并

将t3,t4行的pick改为s（s表示合并到上一个版本）

弹出

修改后

略

wq保存

修改提交信息

弹出

修改后

wq保存，即可合并完成。

可以git log查看

注意：不要rebase那些已经push到仓库的版本

合并分支【场景二】

场景

用merge合并是这样的

想让dev合并到master分支，变成这样，此时需要rebase

实现

1.在提交c4，c3版本后（此时还没合并），先切换到dev分支，执行如下代码。

git rebase master  # 将当dev分支的修改（提交）按顺序应用到 master 分支上
                   # 它会将当前分支的修改（提交）按顺序应用到 master 分支上

此时dev分支log就变成：

master分支log不变

2.所以还得将dev合并到master分支上：先切换到master分支，执行如下命令

git merge dev

此时master分支log

已合并完成，且是一条线，至此结束。

对比

对比merge合并dev

总结

变基git rebase master：相当于将dev红色的基变为master蓝色这条线，将dev1加到最后

所以git rebase master就相当于让dev分支变成：将dev分支节点后的东西，移动到master最新版本的后面所形成的结构，赋给dev。

但此时master还是原样，所以切换到master，将dev合并到master上，即可完成

产生分叉【场景三】

场景

张三在公司写代码写到50%，想着剩下回家再写，就回家了，但他忘记提交到线上仓库。回家后发现未提交，他不能续着写了，写了点其他的新功能，写完后push到线上仓库。第二天到公司后，接着写完剩下的50%，写完后拉取昨天写的代码合并，合并时会产生分叉。现在想要避免分叉

解决

git fetch origin 昨天写的分支
git rebase origin/昨天写的分支

注意

在rebase时可能会产生冲突，此时中断，只需解决完冲突后,执行如下代码即可

git add 解决完冲突的文件
git rebase --continue