[git]merge和rebase的区别

虽然工做中要常用git，可是也就经常使用那么几个命令：pull、push、status、merge、rebase，对git谈不上有多熟悉，加上工做性质不多和同事协同开发，即便出现问题，顶可能是删除项目，从新远程拉取。前几天在头条看到一篇讲merge和rebase的区别的文章，感受蛮不错的，就收藏了，今天发现要用到，想从新复习下，结果提示文章被删除了，还好在百度快照里找到了原文，这里作下记录。如下是原文内容：

前言

我从用git就一直用rebase，可是新的公司须要用merge命令，我不是很明白，因此查了一些资料，总结了下面的内容，若是有什么不妥的地方，还望指正，我必定虚心学习。

merge和rebase

标题上的两个命令：merge和rebase都是用来合并分支的。

这里不解释rebase命令，以及两个命令的原理，详细解释参考这里。（这里的链接可能被百度快照吃掉了）

下面的内容主要说的是二者在实际操做中的区别。

什么是分支

分支就是便于多人在同一项目中的协做开发。比方说：每一个人开发不一样的功能，在各自的分支开发过程当中互不影响，完成后都提交到develop分支。极大的提升了开发的效率。

合并分支

每一个人建立一个分支进行开发，当开发完成，须要合并到develop分支的时候，就须要用到合并的命令。

什么是冲突

合并的时候，有可能会产生冲突。

冲突的产生是由于在合并的时候，不一样分支修改了相同的位置。因此在合并的时候git不知道那个究竟是你想保留的，因此就提出疑问（冲突提醒）让你本身手动选择想要保留的内容，从而解决冲突。

merge和rebase的区别

处理冲突的方式：

• 使用merge命令合并分支，解决完冲突，执行git add .和git commit -m'fix conflict'。这个时候会产生一个commit。
• 使用rebase命令合并分支，解决完冲突，执行git add .和git rebase --continue，不会产生额外的commit。这样的好处是‘干净’，分支上不会有无心义的解决分支的commit。

git pull和git pull --rebase区别：git pull作了两个操做分别是‘获取’和合并。因此加了rebase就是以rebase的方式进行合并分支，默认为merge。

以一张图的形式merge和rebase的区别展现：

总结：个人简单理解——merge显性的处理冲突，rebase隐性的处理冲突。

git merge和git merge --no-ff的区别

我本身尝试merge命令后，发现：merge时并无产生一个commit。不是说merge时会产生一个merge commit吗？

注意：只有在冲突的时候，解决完冲突才会自动产生一个commit。

若是想在没有冲突的状况下也自动生成一个commit，记录这次合并就能够用：git merge --no-ff命令，下面用一张图来表示二者的区别：

 

如何选择合并分支的方式

个人理解：主要是看那个命令用的熟练，可以有效的管理本身的代码；还有就是团队用的是那种方式。

我对于rebase比较熟悉，因此我通常都用rebase，可是如今的公司用的是merge --no-ff命令合并分支。因此，我在工做上就用merge，我的项目就用rebase。

也能够二者结合：

• 获取远程项目中最新代码时：git pull --rebase，这个时隐性的合并远程分支的代码不会产生而外的commit。

• 合并到分支的时候：git merge --no-ff，自动一个merge commit，便于管理（这看管理人员怎么认为了）

总结

• 合并时，没有冲突的状况下二者同样。（我认为，若是理解错了还望指正）
• merge显性处理冲突
• rebase隐性处理冲突