merge与rebase的区别

假设我们有如下图一所示仓库，该仓库有master和develop两个分支，且develop是在（3.added merge.txt file）commit处从master拉出来的分支。
image.png
图一

merge

假设现在HEAD在（6.added hello.txt file）处，也就是在master分支最近的一次提交处
此时执行git merge develop, 结果如下图所示。
image.png
image.png
图二

工作原理就是：git 会自动根据两个分支的共同祖先即 (3.added merge.txt file)这个 commit 和两个分支的最新提交即 (6.added hello.txt file) 和 (5.added test.txt file) 进行一个三方合并，然后将合并中修改的内容生成一个新的 commit，即图二的(7.Merge branch ‘develop’)。
这是merge的效果，简单来说就 合并两个分支并生成一个新的提交。
[

](https://blog.csdn.net/michaelshare/article/details/79108233)

rebase

那rebase是这么工作的呢？
假设初始状态也是图一所显示的。两个分支一个master，一个develop
此时HEAD在（6.added hello.txt file）处，现在执行 git rebase develop ,结果如下图三所示。
image.png
image.png
图三
可以看见develop分支分出来分叉不见了，下面来解释一下它的工作原理：
在执行git rebase develop之前，HEAD在（6.added hello.txt file）处，当执行rebase操作时，git 会从两个分支的共同祖先 (3.added merge.txt file)开始提取 当前分支（此时是master分支）上的修改，即 （6.added hello.txt file）这个commit，再将 master 分支指向 目标分支的最新提交（此时是develop分支）即（5.added test.txt file） 处，然后将刚刚提取的修改应用到这个最新提交后面。如果提取的修改有多个，那git将依次应用到最新的提交后面，如下两图所示，图四为初始状态，图五为执行rebase后的状态。
image.png
图四
image.png
图五
简单来说，

  1. rebase将本分支（master）的所有公共节点之后的commit额外保存并从此分支删除。
  2. 将当前公共节点指向合并分支(dev)举个例子
  3. 将之前额外保存的本分支（master）的所有公共节点之后的commit移动到合并分支（dev）的末尾

merge OR rebase

那什么时候用merge，什么时候用rebase呢？
再举个例子：
初始状态如下图六所示：
和之前一样的是，develop分支也是在 (3.added merge.txt file)处从master分支拉取develop分支。不一样的是两个分支各个commit的时间不同，之前develop分支的4和5commit在master分支3之后6之前，现在是develop分支的4提交早于master分支的5提交，develop分支的6提交晚于master的5提交早于master的7提交。
image.png
图六
在上图情况下，在master分支的7commit处，执行git merge develop，结果如下图七所示：
image.png
image.png
图七
执行git rebase develop，结果如下图八所示：
image.png
image.png
图八

  1. 可以看出merge结果能够体现出时间线，但是rebase会打乱时间线。
  2. 而rebase看起来简洁，但是merge看起来不太简洁。
  3. 最终结果是都把代码合起来了，所以具体怎么使用这两个命令看项目需要。

还有一点说明的是，在项目中经常使用git pull来拉取代码，git pull相当于是git fetch + git merge，如果此时运行git pull -r，也就是git pull —rebase，相当于git fetch + git rebase
[

](https://blog.csdn.net/michaelshare/article/details/79108233)