git中rebase(变基)和merge(合并)区别

简介

  以前用git基本上针对git flow以及基本的git操作命令基本上满足日常开发需求,其实也没必要过于深究,常用命令80-90%基本上满足我们正常使用了。 但是其实很多人,包括我自己,git的官方文档基本没扫完一遍,所以抽时间其实几个小时也就能看完的事情。 其中在合并branch的时候，网上有很多关于使用git rebase 还是 git merge有无数篇文章进行所谓的争论。
  甚至有标题党文章也是耸人听闻,语不惊人死不休。“git合并代码永远用rebase”…文章我也是懒得吐槽了,后面搬出官方文档来大家自行判断。

merge分析

  先举例git merge画图分析.

  如图所示,develop合并到master会产生一个commit, 我们称之为"merge commit". 并且图上能够展现完整开发过程,“commit"分叉.很多人比较反感的是多出来的
这个没有意义的commit以及分叉没必要存在,所以接下来提到rebase(变基). 我们现在重点看一下此时"c4"的父亲是"c3”.

rebase分析

  和上面情况不巧的是, 在Develop基于master c3切出来分支以后, master有人往上面提交到了代码.这时候变成这样

如果develop要把master merge进来则展现为这样:

如果改为develop rebase master呢? 如图:

首先的改变是,c4 c5 c6的hash值发生了变化, c4的父亲"变基"了, 父节点之前是"c3"现在是"c3-1". 没有多出来一个merge commit(c6-1)。此时就不出现了"分叉",所有的提交都在一条线上. 其实最通俗理解,
之前develop从c3切出来的,现在从c3-1切出来。(网上一堆花里胡哨的解释…,没想象中那么复杂)。

总结

  rebase 和 merge优缺点和用法各个团队不一样,因人而异,业界没有定论。如果没有充分理解rebase, 还是老老实实用merge吧。用merge肯定在功能上不会出问题的! 引用官方文档一句话:

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。 – git官方文档, "变基介绍"最后一段话

git文档: git官方文档