“
我的数学一向不错,上次我暗恋的女生问我题目:你不是数字好吗,问你个题,1+9+0=?。这么简单的题能难得倒我,我随口一答:10。然后她哭着跑开了,还说:活该你没女朋友。
”
这几天朋友圈都被长生生物这个怪物给霸占了,笨叔发的点滴都没啥人看了,上面那个段子,大家可以留言,那个女生想表达啥意思?
大家可能都知道git这个生物吧,他是由Linux祖师爷创造出来的,短短十来年时间已经霸占了代码版本管理软件的头把交椅,连不可一世的微软也在偷偷摸摸的开始偷偷使用git了,你说git的发展速度是不是和细胞繁殖一样。
大家知道git天生就喜欢分支,那么分支管理里有一个重要的方面就是分支合并了。git提供了两个分支合并的命令,一个是git merge,另外一个是git rebase,他们究竟有啥区别呢?
01 究竟有啥区别?
—
我们假设一个 git 仓库里有一个 master 分支,另外还有一个 dev 分支。如下图所示。
上述ABCDEFG这几个节点(每个节点是一个commit)都是按照时间顺序来提交的,如下表所示。
|
节点 |
提交时间 |
|
A |
7月1 号 |
|
B |
7月2 号 |
|
C |
7月3 号 |
|
D |
7月4 号 |
|
E |
7月5 号 |
|
F |
7月6 号 |
|
G |
7月7 号 |
也就是:
-
master分支上有:A->B->C->E 这4个节点
-
dev分支上有: A->B->D->F>G 这个5个节点
每个节点代表一个commit。
那么如果执行如下两个命令:
$ git merge master
$ git rebase master
上述两个命令都是将master 分支合并到当前分支,那结果有什么不同呢?
我们先来看merge命令。
git merge master 命令之后, dev 分支变成如下图。
我们可以看到gitmerge master 命令执行之后,dev 分支上的提交都是基于时间轴来合并的。
如果我们执行git rebase master命令,会变成什么样子呢?
git rebase 命令是用来改变一串提交基于那个分支为基础,如git rebase master 就是把dev 分支的D 、F 和G 这三个提交基于最新的master 分支上,也就是基于E 这个提交之上。git rebase 的一个常见用途是保持你正在开发的分支(如dev 分支)相对于另外一个分支(如master 分支)是最新的。
02 不如动手实验
—
上面说了一通,不如动手做实验。
比如我们在本地建一个git,创建如下master分支上的节点。
master分支上有ABCE这4个节点。
接下来我们创建dev分支上的ABDFG这5个节点,如下图所示。
那我们现在master分支和dev分支都建好了,下面就可以开始实验啦。我们先试试git rebase master吧。
$ git checkout dev
$ git rebase master
上述命令执行完成之后,我们来看看dev分支的情况。
执行结果是不是和我们预期的一样。dev分支和master分支是从B这个节点开始分叉的,rebase命令会让当前分支(dev分支)的节点DFG这3个节点,从master节点最后一个节点E开始生长,所以这个命令之后,dev分支最后的结果就是A->B>C->E->D->F->G
下面看一下git merge master命令。
$git checkout dev
$git merge master
最后执行的结果如下:
和我们的预取是一样一样的。merge之后的结果如下:
A->B->C->D->E->F->G->merge节点
03 总结一下吧
merge和rebase命令都是用来合并分支,那什么时候用merge命令和rebase命令呢?
Ø 当你需要合并别人的修改,可以考虑使用merge命令,如项目管理上需要合并其他开发者的分支。
Ø 当你的开发工作或者提交的补丁需要基于某个分支之上,那用rebase命令,如给Linux内核社区提交补丁。