git rebase 与 merge 的那些事儿~（详细图解，通俗易懂）

什么是 rebase?

• git rebase 你其实可以把它理解成是“重新设置基线”，将你的当前分支重新设置开始点。这个时候才能知道你当前分支于你需要比较的分支之间的差异。

• 原理很简单：rebase 需要基于一个分支来设置你当前的分支的基线，这基线就是当前分支的开始时间轴向后移动到最新的跟踪分支的最后面，这样你的当前分支就是最新的跟踪分支。这里的操作是基于文件事务处理的，所以你不用怕中间失败会影响文件的一致性。在中间的过程中你可以随时取消 rebase 事务。

  官方解释: https://git-scm.com/book/zh/v2/Git-分支-变基

  那么 git rebase 和 git merge 到底有啥区别？

  rebase 会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。

• eg: 如果你从 master 拉了个 feature 分支出来,然后你提交了几个 commit ,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit ,如果这个时候你 rebase develop 的话，就会把你当前的几个 commit，放到那个人 commit 的后面。

而 merge 会把公共分支和你当前的 commit 合并在一起，形成一个新的 commit 提交

上图解：

如下图所示，bugfix 分支是从 master 分支分叉出来的。

使用 rebase 之后：

现在我们来简单地讲解一下合并的流程吧。

• 首先，rebase bugfix 分支到 master 分支, bugfix 分支的历史记录会添加在 master 分支的后面。如图所示，历史记录成一条线，相当整洁。

• 这时移动提交 X 和 Y 有可能会发生冲突，所以需要修改各自的提交时发生冲突的部分。

• rebase 之后，master 的 HEAD 位置不变。因此，要合并 master 分支和 bugfix 分支，即是将 master 的HEAD移动到 bugfix 的 HEAD 这里。

使用 merge 之后：

• merge 会把两个分支合并在一起，形成一个新的 commit 提交

注意:

尽量不要在公共分支使用 rebase
本地和远端对应同一条分支,优先使用 rebase ,而不是 merge

因为往后放的这些 commit 都是新的,这样其他从这个公共分支拉出去的人，都需要再 rebase,相当于你 rebase 东西进来，就都是新的 commit 了

1-2-3 是现在的分支状态
这个时候从原来的 master , checkout 出来一个 prod 分支
然后 master 提交了4.5，prod 提交了6.7
这个时候 master 分支状态就是1-2-3-4-5，prod 状态变成1-2-3-6-7
如果在 prod 上用 rebase master , prod 分支状态就成了1-2-3-4-5-6-7
如果是 merge
1-2-3-6-7-8
........ |4-5|
会出来一个8，这个8的提交就是把4-5合进来的提交

** merge 和 rebase 实际上只是用的场景不一样**
更通俗的解释一波.

• 比如 rebase,你自己开发分支一直在做,然后某一天，你想把主线的修改合到你的分支上,做一次集成,这种情况就用 rebase 比较好.把你的提交都放在主线修改的头上
• 如果用 merge，脑袋上顶着一笔 merge 的8,你如果想回退你分支上的某个提交就很麻烦,还有一个重要的问题, rebase 的话,本来我的分支是从3拉出来的, rebase 完了之后,就不知道我当时是从哪儿拉出来的我的开发分支
• 同样的,如果你在主分支上用 rebase , rebase 其他分支的修改,是不是要是别人想看主分支上有什么历史,他看到的就不是完整的历史课,这个历史已经被你篡改了

觉得有帮助的小伙伴点个赞~