git rebase 与 git merge 的区别

前言

初学git，在合并分支上一定会经常使用到 git merge 语法。今日接触到 git rebase，发现两者都有用于分支合并的功能，那接下来让咱们探究一下两者的不一样之处。

开门见山：两者的区别

主要区别在于git log上：是否保留分支的commit提交节点 。

其次细讲：详情分析

前提：

1. 在一个git项目中我先建立并保存了两个文档：1.txt 和 2.txt 记做“1” 和 “2”；
2. 建立分支branch1；
3. 继续在主分支Master上建立并保存两个文档：3.txt 和 4.txt 记做“3” 和 “4”；
4. 转到branch1分支上建立 5.txt 和 6.txt 记做“5” 和 “6”；

此时，咱们的主分支Master上有一、二、三、4 四个文档，branch1分支上则是一、二、五、6 四个文档，接下来执行咱们的合并操做。

• git merge：

  咱们直接回到主分支Master上执行 git merge 命令，显示以下：

此时咱们的 git log 上保留了分支branch1的 5 和 6 的commit提交，且又在主分支Master上自动建立了一个新的commit提交节点 “7”。

简单而言就是Master的一、二、三、4和合并的branch1的五、6的提交历史节点都被记录下来了，且自动在Master上自动生成第7个节点：

• git rebase：

  咱们在分支branch1上执行 git rebase 命令：

会发现branch1合并了 Master 的 三、4 文档，因此如今branch1 就有了一、二、三、四、五、6全部文档，回到Master再合并一下：

这时咱们的 git log 上就获得一个简洁的项目历史，且未生成新的 merge commit（保留了分支上的提交信息成功与Master合并，但删去了提交历史记录）：

• 自我猜测：

学完rebase，我即刻猜测，如果在分支baranch1上直接merge合并主分支，获得全部文档后再回到主分支上执行merge会不会也能获得一条线，事实证实，这么想说明仍是没有彻底理解rebase的真正含义，先看结果吧...

rebase 究竟是什么？

rebase就是——变基， 变基， 变基 。

即：改变一条分支的 基点 ，使原分支从指定的节点（commit）延续。。

通俗点讲，变基操做其实就是保留了该 commit 做出的修改，但删丢弃了分支上一些现有的提交记录，删去了这些节点。

最后结论：两者比较

比较	merge	rebase
优势	保留有价值的历史文档	删减就繁
缺点	分支杂乱冗余	没法体现时间线

因此，使用merge仍是rebase仍是得分状况考虑，具体项目具体分析：

• 若是项目庞大，须要一个简洁的线性历史树便于leader管理，推荐使用 git rebase 。
• 若是是小型项目，须要审查历史纪录来便于编写过程报告，则推荐使用 git merge 。