git rebase 各种场景及现象
git rebase 各种场景及现象
场景1:
步骤:
master上拉出一个分支branch1。
branch1提交一个commit,时间是9点。
master上提交一个commit,时间是10点。
此时graph
![image-20210922112934966](https://img2020.cnblogs.com/blog/1768648/202109/1768648-20210922154421710-682782819.png)
执行以下命令
git checkout branch1
git rebase master
git checkout master
git merge brnch1
![image-20210922113258266](https://img2020.cnblogs.com/blog/1768648/202109/1768648-20210922154422035-2104895240.png)
现象:
在master分支上,branch1提交的9点commit竟然排在顶端,而master提交的10点commit排在之后。
总结:
变基的原理是首先找到这两个分支(即当前分支 branch1、变基操作的目标基底分支master) 的最近共同祖先 (===========这个commit),然后对比当前分支相对于该祖先的历次提交,提取相应的修改并存为临时文件, 然后将当前分支指向目标基底 master(添加文件file1这个commit), 最后以此将之前另存为临时文件的修改依序应用。
所以虽然branch1提交commit是9点的,master提交commit是10点,但是branch1的提交是最新的,排在master的顶端,并且这个commit不再是branch1提交的commit,而是新生成的补丁commit。
参考:https://git-scm.com/book/zh/v2/Git-分支-变基
场景2:
master拉出两个分支,一个branch1,一个branch2
branch1,branch2均提交一个commit
此时的graph
![image-20210922121705659](https://img2020.cnblogs.com/blog/1768648/202109/1768648-20210922154423728-1965167257.png)
branch1先rebase master
branch2再rebase master
master先merge branch1
此时的graph
![image-20210922122020953](https://img2020.cnblogs.com/blog/1768648/202109/1768648-20210922154429425-897946935.png)
master再merge branch2
此时会出现merge branch ’branch2‘提示(变成了正常的merge)
![image-20210922122209267](https://img2020.cnblogs.com/blog/1768648/202109/1768648-20210922154429919-611645773.png)
push branch2以后的graph
![image-20210922122231066](https://img2020.cnblogs.com/blog/1768648/202109/1768648-20210922154430433-157601713.png)
现象:
master合并branch1是rebase的方式,合并branch2是merge的方式。
总结:
看起来,两个顺序的rebase,只有首个生效。这是因为我使用的同一台机器的缘故。
同样的测试,使用两台电脑,master合并branch1是rebase的方式,合并branch2也是rebase的方式。但是branch1 push以后,branch2 push会提示落后分支,需要进行git pull --rebase
才可以进行push操作。