问“git merge”和“git rebase”有什么区别？

git rebase就是那种典型的，使用MVC模型的时候喜欢想着用Model来代替View的这种人，会喜欢做的事情。其实也没有什么好和不好，但是保留原始数据显然是相当重要的。你嫌图形不好看的话，自己写一个程序去画就好了。就像没有人会在SQLServer里面真的用一棵树来表示树形的留言一样。

两个使用场景是不一样的，merge只是合并另外一个分支的内容，rebase也合并另外一个分支的内容，但是会把本分支的commits顶到最顶端假设我们现在有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)另外，单独使用rebase，还有调整当前分支上commits的功能(合并，丢弃，修改commites msg)PS:其他知友的答案都说到冲突的问题，1. 用merge确实只需要解决一遍冲突，比较简单粗暴2. 用rebase有时候会需要多次fix冲突（原因在于本地分支已经提交了非常多的commit，而且很久都没有和上游合并过）我个人推荐大家开发的时候，尽量及时rebase上游分支（我习惯是每周merge一次），有冲突提前就fix掉，即使我们自己的分支开发了很久（哪怕是几个月），也不会积累太多的conflict，最后合并进主分支的时候特别轻松， 非常反对从master check出新分支，自己闷头开发几个月，结果最后merge进主分支的时候，一大堆冲突，自己还嗷嗷叫的行为