提起rebase就不得不提merger,开发中一直都是机械的使用,固定的场景固定的用法,很少去了解内部,只是知道个大概,我开发中是最先使用的rebase后用的merge,刚用git时都是老司机带,教你几个命令够用了就行了;
比较merge和rebase,一定要先理解rebase这个词的意思,这可不是现成的英文单词,它只是一个简写:Reapply commits on top of another base tip--将commit在新的base的top重新apply,也就是很多人所说的变基.merge是什么意思呢?看一下官方的描述:Join two or more development histories together--将两个或者更多的开发历史合并.
这样说未免抽象,举个例子,假设当前有两个分支 master和dev,分支状态如下:
master:
dev分支:
相信你已经很明白了,master是起始分支,在master_1提交之后,新建了dev分支且在dev分支有dev_1和dev_2两次commit.
在此场景下分别使用一下rebase和merge,前提是当前所在的分支是master分支的top--master_3处即如下图,注意红框中的master_3的commit ID值:
命令为: git rebase --onto dev --root master(简写即git rebase dev)后结果如何呢?看下图:
注意在master_1这个commit之后master这个commit之前加入了dev分支的两个commit,注意之前在master分支上的master_3这个commit的id有了变化,有之前的f0d2c8变成了b7b2a59.通过上图的比较很容易可以总结出rebase这个命令的作用:将master分支和dev的共同基点(即master_1这个commit,以下以基点代替)之后所有的新commit撤销(即将master和master_3两个commit撤销),放入一个暂存区patch中,然后将dev分支上的所有新的commit(dev_1和dev_2),插入到了master分支的基点之上,然后再把patch中暂存的commit(此时为master和master_3两个commit)重新应用在master分支的top,因为之前的commit已经被撤销,所以生成的新的commit会有新的commit id生成;
merge比较简单直接一幅图就说明白了,现状如下:
敲入命令:
git checkout master(当前分支为master)
git merge dev
此时git情况是:
再看看master_3的commit id
关于黄金法则
官方说明:“No one shall rebase a shared branch” — Everyone about rebase,即不要在共享分支上rebase;
其实我们在开发中,很多时候是N个同事共同在一个分支上(比如dev分支)开发同一个版本的各个模块.很多人就是碍于黄金法则上说不要在共享分支rebase,投鼠忌器索性不使用rebase了,这就舍本逐末了,除了可以合并多个commit,在分支合并上也可以使用,最典型的场景就是:你和你同事都在dev分支上开发,你同事做了一些commit,并且已经被铺设到中央库的deve分支,此你rebase到origin/dev分支的操作并不违反rebase的黄金定律,因为:只有你的local本地私有(还未push的)commits被移动和重写历史了,而你的本地commit之前的所有commit都未做改变在大多数情况下,这种rebase比用merge要好很多;