git rebase 各种场景及现象
git rebase 各种场景及现象
场景1：
步骤：
master上拉出一个分支branch1。
branch1提交一个commit，时间是9点。
master上提交一个commit，时间是10点。
此时graph
执行以下命令
git checkout branch1
git rebase master
git checkout master
git merge brnch1
现象：
在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
branch1先rebase master
branch2再rebase master
master先merge branch1
此时的graph
master再merge branch2
此时会出现merge branch ’branch2‘提示（变成了正常的merge）
push branch2以后的graph
现象：
master合并branch1是rebase的方式，合并branch2是merge的方式。
总结：
看起来，两个顺序的rebase，只有首个生效。这是因为我使用的同一台机器的缘故。
同样的测试，使用两台电脑，master合并branch1是rebase的方式，合并branch2也是rebase的方式。但是branch1 push以后，branch2 push会提示落后分支，需要进行git pull --rebase才可以进行push操作。
