前几天写过一篇文章《这些必须具备的Git开发技能，你知道吗？》，主要讲的是自己在工作中Git的使用技巧，相信大家应该有所收获，今天主要针对merge和rebase命令来做深入的讲解。
作用
git merge与git rebase的作用是相同的，都是用于合并指定分支到当前分支，而且都是针对于本地分支来说的
不同点-提交记录
虽然两者的作用是相同的，但是对于工作流和提交记录来说，是有很大差别的，下面我们通过实际的例子来讲述。
从图中可以看出在远程master分支和本地master分支上出现了不同的commit，左侧是本地master，右侧是远程master
两个master分支的不同commit
当我们使用git merge后，提交记录显示为
git merge后的分支
当我们使用git rebase后，提交记录显示为
git rebas后的分支
从两幅图的差异可以看出，git merge会保留原始的提交记录，git merge合并分支后，产生了一个新的提交，HEAD指向该新的提交，而且从下面的图中可以看出git merge产生的新提交区别于正常的提交，提交的Hash值后有一个M标识，而且在颜色上淡于正常的提交。
git merge提交记录
而使用git rebase合并分支后，分支呈现线性展示，原始的提交记录“消失”了，而且HEAD处并没有新的提交，而是指向最近的一次本地提交。
产生这种差异的原因是什么呢？
因为在使用git rebase的时候，git会将待合并的分支上的每个提交记录clone一份，从本地分支有不同提交记录的时候分开，首先将远程分支的提交记录合并到分开的位置，然后将本地分支提交的clone部分从后面重新链接上，如果有冲突就需要解决冲突。
不同点-解决冲突
假如遇到冲突的时候，两者解决冲突的方法也是不一样的。
在git merge出现冲突时，会提醒用户一次性解决所有提交记录的冲突，一般会有如下的提示，CONFLICT会提示多次
git merge冲突提示
在解决完冲突后，可以使用git add与git commit完成提交。
而在git rebase的时候，如果本地文件与远程文件有多次提交记录的差异，则需要针对每一次提交记录进行更改，在解决完一次提交记录冲突后再使用git add与git rebase --continue。如果在git rebase --continue时出现以下提示，则表明还有其他的提交记录需要解决冲突，然后重复上述的步骤。这就可以看出在使用rebase的时候，如果出现了冲突，它的解决方案是要比merge的更麻烦的。
git rebase提示
总结
通过上面的分析我们知道，使用merge后会保留原始提交的记录，在git tree中可以查看到完整的提交路线；而使用rebase则会使我们的git tree看起来更加清爽，更方便去维护。
使用merge和rebase都能达到合并分支的作用，我们不强制使用哪一个，一般会根据团队使用习惯，但是只要我们掌握了原理，使用哪个都有游刃有余。
如果喜欢的话，记得关注小编噢，小编后续会坚持出更多技术性的文章，如果有任何问题，也欢迎提问，小编都会尽力解答的。