前言
我们在上篇文章你想知道的所有Git分支命令都在这中提到了git merge命令，可以将其中一个分支的代码合并到另一个分支中，其实还有另一种方法，通过 git rebase命令也可以实现，但是两者的实现方式还是有很大差异的，网上有很多文章都对其差异有讲解，但大多数说的都很模糊不够清晰，看的也是一知半解，如果一篇文章对读者而言做不到通熟易懂那就是对读者的不负责，本篇文章将使用最通熟易懂的语言让你彻底搞懂两者的差异。
先说结论：
- merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容
- merge 的提交历史记录了实际发生过什么，关注点在真实的提交历史上面
- rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面
- rebase 操作会丢弃当前分支已提交的 commit，故不要在已经 push 到远程，和其他人正在协作开发的分支上执行 rebase 操作
- merge 与 rebase 都是很好的分支合并命令，没有好坏之分，使用哪一个应由团队的实际开发需求及场景决定
先来说说 git merge的实现方式
如上图所示，我们有两个分支，master分支和test分支，test分支是基于master分支在B处的提交节点创建的，在创建后master分支又经过迭代提交了两次，从C到D节点，test分支也基于B往前继续更新了两次，到了F节点。两者从B开始就走向了分叉。
这时如果我们想将test分支合并到master分支，通过merge是如何工作的呢？
//将分支切换到master分支
git checkout master
//把test分支合并到master分支
git merge test
复制代码从图中可以看到，这里生成了一个新的提交G，是怎么生成的呢？ merge 命令 它会把两个分支的最新快照（F、E 和 D、E）以及二者最近的共同祖先（B）进行三方合并，合并的结果是生成一个新的快照G（并提交）。
git rebase实现方式
//将分支切换到master分支
git checkout master
//把test分支合并到master分支
git rebase test
复制代码从图就可以看出和merge命令不同
这里有个名词定义我们先简单说明一下
- test:基分支、目标分支
- master:待变基分支，当前分支
官方解释： 当执行rebase操作时，git会从两个分支的共同祖先开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面。
这句话听起来可能绕绕的，不用怕，听小蛋给你好好翻译翻译：
我们结合具体例子来说明，当我们在master (待变基分支)上执行git rebase test(基分支)时,git就会从两者的共同祖先B开始，提取master分支上的修改，也就是C,D两个commit,提取到之后git会先保存起来，然后将master分支指向test分支最新提交的节点，也就是F节点，然后把提取到的C,D接到F后面，在这个过程当中，会删除原来的C,Dcommit记录，生成新的C‘，D'，虽然C',D'和原来的C,Dcoommit的内容是一样的，但是commit id是不同的。
rebase操作如果用一句话进行解释就是改变基底。master分支原来的基底是A，现在变成了以test分支最新的提交F做为新的基底了。
总结
git和rebase这两者哪种操作更好，这是取决于不同的场景的。
当我们拉取公共分支最新代码的时候建议使用rebase，也就是git pull -r或git pull --rebase，但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛。（如果使用merge，多出无意义的一条提交记录）。
往公共分支上合代码的时候，使用merge。（如果使用rebase，那么其他开发人员想看主分支的历史，就不是原来的历史了，历史已经被你篡改了），例如主分支是master分支,小蛋我有一个egg分支，我在egg分支上写了很多垃圾代码，然后这时候我把egg分支通过rebase命令 合并到master分支，那对于master分支来说，它之前到提交历史就没了，别的同事突然想看master分支以前的提交历史，其实就看不到了，发现只能看到我egg的提交历史，估计同事会把我的egg捏碎的，这种傻事可不要干哟。
