git中merge和rebase的区别
1.采用merge和rebase后，git log的区别，merge命令不会保留merge的分支的commit： 2.处理冲突的方式： ·（一股脑）使用merge命令合并分支，解决完冲突，执行git add .和git commit -m'fix conflict'。这个时候会产生一个commit。 ·（交互式）使用rebase命令合并分支，解决完冲突，执行git add .和git rebase --continue，不会产生额外的commit。这样的好处是，‘干净’，分支上不会有无意义的解决分支的commit；坏处，如果合并的分支中存在多个commit，需要重复处理多次冲突。 3.git pull和git pull --rebase区别：git pull做了两个操作分别是‘获取’和合并。所以加了rebase就是以rebase的方式进行合并分支，默认为merge。 举个例子： 假设我们现在有3个分支 master分支：线上环境使用的分支 testing分支：测试环境使用的分支 my_feature分支：开发新功能的分支，也就是当前分支 A. 假设我在my_feature上开发了一段时间，之后另外的同事开发的功能正式上线到master分支了，那么我可以在当前的分支下rebase一下master分支，这样我这个分支的几个commits相对于master还是处于最顶端的，也就是说rebase主要用来跟上游同步，同时把自己的修改顶到最上面 B. 我在my_feature上开发了一段时间了，想要放到testing分支上，那就切到testing，然后merge my_feature进来，因为是个测试分支，commits的顺序无所谓，也就没必要用rebase (当然你也可以用rebase) 原理： http://gitbook.liuhui998.com/4_2.html
rebase和merge区别是什么?
Merge具有更高的可追溯性，而Rebase则更整洁且易于审核。Merge合并将在您的特征分支中将更改集成，并创建一个新的提交F. F是合并开发分支的提交，如果有的话，对冲突进行排序。此方法将为特征分支带来Develp分支的更改，即A和B。现在，您的特征分支上的提交是C，A，D，B，E，F.有3个添加到您的功能分支中的其他提交。Rebase另一方面，rebase会移动整个功能分支，就像它从一开始就从开发分支的最新提交分支出来一样。Rebase将首先搜索功能分支的基础，然后将其更改为开发分支B上的最新提交，然后根据该基础B将所有提交重新应用到功能分支上。Rebase实际上是创建新提交，C’，D’，E’。原始提交保持不变。最后，它将要素分支指向的要素从E更改为E’。
