git rebase 与 git merge 的区别
前言
初学git，在合并分支上必定会常用到 git merge 语法。今日接触到 git rebase，发现二者都有用于分支合并的功能，那接下来让我们探究一下二者的不同之处。
开门见山：二者的区别
主要区别在于git log上：是否保留分支的commit提交节点 。
其次细讲：详情分析
前提：
- 在一个git项目中我先创建并保存了两个文档：1.txt 和 2.txt 记作“1” 和 “2”；
- 创建分支branch1；
- 继续在主分支Master上创建并保存两个文档：3.txt 和 4.txt 记作“3” 和 “4”；
- 转到branch1分支上创建 5.txt 和 6.txt 记作“5” 和 “6”；
此时，我们的主分支Master上有1、2、3、4 四个文档，branch1分支上则是1、2、5、6 四个文档，接下来执行我们的合并操作。
-
git merge：
我们直接回到主分支Master上执行 git merge 命令，显示如下：
image.png
此时我们的 git log 上保留了分支branch1的 5 和 6 的commit提交，且又在主分支Master上自动创建了一个新的commit提交节点 “7”。
简单而言就是Master的1、2、3、4和合并的branch1的5、6的提交历史节点都被记录下来了，且自动在Master上自动生成第7个节点：
image
-
git rebase：
我们在分支branch1上执行 git rebase 命令：
image
会发现branch1合并了 Master 的 3、4 文档，所以现在branch1 就有了1、2、3、4、5、6所有文档，回到Master再合并一下：
image
这时我们的 git log 上就得到一个简洁的项目历史，且未生成新的 merge commit（保留了分支上的提交信息成功与Master合并，但删去了提交历史记录）：
image
- 自我猜想：
学完rebase，我即刻猜想，若是在分支baranch1上直接merge合并主分支，得到所有文档后再回到主分支上执行merge会不会也能得到一条线，事实证明，这么想说明还是没有完全理解rebase的真正含义，先看结果吧...
image
rebase 到底是什么？
rebase就是——变基， 变基， 变基 。
即：改变一条分支的 基点 ，使原分支从指定的节点（commit）延续。。
通俗点讲，变基操作其实就是保留了该 commit 作出的修改，但删丢弃了分支上一些现有的提交记录，删去了这些节点。
最后结论：二者比较
| 比较 | merge | rebase |
|---|---|---|
| 优点 | 保留有价值的历史文档 | 删减就繁 |
| 缺点 | 分支杂乱冗余 | 无法体现时间线 |
所以，使用merge还是rebase还是得分情况考虑，具体项目具体分析：
- 如果项目庞大，需要一个简洁的线性历史树便于leader管理，推荐使用 git rebase 。
- 如果是小型项目，需要审查历史纪录来便于编写过程报告，则推荐使用 git merge 。
