一文读懂merge和rebase区别

什么是rebase？

• rebase就是re + base，re表示“从新”，base表示“基础”，即“变换基础”的意思
• rebase从本质上讲就是变换一个或多个commit的基础，也就是上游commit，而用来作合并操做只是rebase的一种应用场景
• rebase在变换一系列commit基础的同时，还让咱们有机会去整理这些待rebase的commit，好比合并多个commit，修改某次commit等

这些就是rebase命令的本质,因此rebase和merge自己并不该该直接做为两种合并代码的方式来比较，正确认识rebase命令是一个很重要的前提

固然，本文主要从代码合并的场景来比较rebase和merge的区别

合并时的核心区别

rebase会改变提交历史；merge则会保留真实的历史

合并时的其余区别

• merge若是不能快进合并（fast forward），就会造成一个额外的合并提交；rebase不会造成新的合并提交（但会生成要rebase的一系列commit的副原本作变基）
• rebase可用来整理待变基的一系列提交记录，好比合并多个提交等；merge没有这个功能

注意点

merge相对可靠，而使用rebase要注意两点

• 当对已push到远程的提交作rebase操做时，可能会形成远端的提交历史和其余人本地不一致（因此最好不要这么作，好比想合并多个commit成一个，要先确保这些commit没有push到远端）
• rebase后看不到真实的历史记录了（这一点看团队规范，有的团队喜欢rebase后一条线性的历史记录；但我建议用merge，虽然历史记录相对错综复杂但好在真实，能够经过历史记录清楚的看到代码演进的过程，而从复杂的历史中剖析问题则是咱们或者其余辅助工具应该在上层作的工做）

合并代码log图解

合并后能够看到真实的提交历史，merge后造成H这个新的合并提交（若是可快进合并则不会产生新的提交；若是可快进合并但在merge时使用了--no-ff，则仍是会产生一个新的合并提交；--no-ff好处是能够从历史记录清楚的看到作了一个合并操做，而不会由于快进合并致使历史成为一条线）

在topic上rebase master时，git会从topic的A、B、C复制出三个新的提交（原先的A、B、C以后会被git回收掉）依次添加到master上的G提交后（可能出现三次重复的冲突，思考下为何？能够经过git rerere来解决，不展开说了），rebase完成后历史记录变成了一条线