Git必学的merge和rebase区别

一、git merge

场景一 ：先pull再commit

我们模拟本地pull代码之后，push时远程同时有代码提交，导致本地push失败的情况。

首先，我们在GitHub的dev分支上的GitDemo这个类里，去更新第14行，如下：

远程commit代码后。在本地也同时修改该类的第14行，如下：

直接commit and push代码时，结果如下图：

毫不意外，push was rejected，因为出现了代码冲突，远程和本地修改了同一个地方。我们merge所有代码后，出现下图：

此时，我们再次commit，发现没有可以commit的代码：

那我们查看git log，发现合并好的文件也已经commit，并且git log多了一个commit信息：
我们直接选择push代码：

commit记录有两条，其中一条是合并了最近的一次提交。直接push后，如下：

冲突已经解决，代码成功提交。

场景二：先commit再pull

本地commit后，如果远程更新了代码，本地选择merge模式pull代码。代码有冲突，解决冲突后再次push时，git log 是怎样的？

我们在本地的GitDemo文件中，修改代码并commit：

在远程修改同一行的代码并update：

然后，我们本地进行update code，出现conflicts，选择merge：


merge完毕，进行push操作：

发现已经自动合并代码，不需要我们再次commit，并且commit记录有两条：

二、git rebase

场景一：先pull再commit

如果我们模拟本地pull代码之后，push时远程同时有代码提交，导致本地push失败的情况时。

我们选择的不是merge，而是rebase呢？

我们来复现一下刚才的场景。

同样远程修改代码并提交后，本地也修改同样的地方，这时直接commit&push代码，出现冲突：

这次，我们选择rebase，merge完代码后，出现：

我们选择commit，发现同样没有commit的代码，那就直接push吧：

成功push，并且git log记录里并没有多余的commit信息。

场景二：先commit再pull

本地commit后，如果远程更新代码，本地选择rebase模式pull代码后，代码有冲突，解决冲突后再次push时，git log 是怎样的？

我们复现一下刚才的场景，本地先进行commit：

远程也更新代码：

然后update project：

解决完冲突后push：

发现代码已经合入该次commit信息，无需再次commit，并且没有多余的git log。

三、总结

1、当需要完整的commit记录时，用merge优于用rebase；
2、当对commit记录要求比较清爽时，优先使用rebase

参考链接

Git merge和rebase分支合并命令的区别