一、git pull与git fetch区别

1、两者的区别

两者都是更新远程仓库代码到本地

git fetch相当于是从远程获取最新版本到本地，不会自动merge。只是将远程仓库最新commitid记录更新到本地remote中对应的远程分支，而本地head不更新，仍然保持本地的commitid。

git pull相当于是从远程获取最新版本代码并自动merge。只是将远程仓库最新commitid记录更新到本地remote中，同时本地head也更新到远程拉取下来的commitid记录。 

2、两者的使用 

更新代码一般人都推荐git fetch，之后再自行手动合并，但是麻烦，协作开发，因为代码更新是经常性的

git pull自动合并隐藏过程细节，方便快捷，但是有冲突就麻烦了，不容易对比差异化代码。幸运的是，日常开发中我们解决冲突一般借助于IDE提供的插件，可以很好地对比版本差异，快速解决冲突，所以个人更喜欢用git pull。

二、git merge与git rebase的区别

1、两者的区别

两者都是将公共分支（master）合并到当前分支（feature）

git merge 的合并分支会让两个分支的每一次提交都按照提交时间（并不是push时间）排序，并且会将公共分支（master）和当前分支（feature）的最新一次commit点合并在一起，形成一个新的commit，最终的分支树呈现非整条线性直线的形式。

git rebase操作实际上是将当前分支（feature）的所有commit点取消，保存成一个一个的临时patch（保存在".git/rebase"目录中），然后把当前分支（feature）更新到最新的原分支（master），最后把这些保存的临时patch文件，应用到当前分支（feature）上，并把这些patch重新生成一个个对应新的commit hash值，不会形成新的commit点，可以保持整个分支树的完美线性

  下图更直观

2、两者的场景

git merge适合公共分支，将其他分支合并到公共分支，merge操作两个分支最新的提交点会形成新的一个提交点，使后合并进来的commit记录仍然保持在后边。

git rebase适合个人分支（只自己一个人提交）。日常开发过程中，个人分支代码需要和公共分支代码保持一致最新，定期合并公共分支代码到个人分支。个人分支一般是处于开发阶段，只有个人提交，执行rebase操作后，从公共分支上合并别人新的commit在我们的commit之前。

公共分支：master、develop、和其他人共同使用的feature，统称为公共分支。

个人分支：只有自己一个人开发提交代码，不存在第二个人提交，统称为个人分支

为什么不要再公共分支使用rebase

假设现在master（公共分支）主分支要把上线后release分支合并进来

master是公共分支，每次上线后的release分支都要合并进来，开发新功能也要从maser拉取新分支。

现在在master上执行rebase操作。会把从release合并过来的commit放在master现有commit的最前边，作为最早的提交，而把master现有的每个提交创建全新的提交来重写项目历史记录，放在maser最后边，作为最新的commit。这样打乱且篡改了历史提交记录。若别人想看公共分支的历史提交记录，它看到的不是完整的历史记录，因为已经被你打乱篡改了。

而且正在开发的其他分支会定期从master上合并代码，使开发分支保持最新，由于在master执行了rebase，maser历史会形成全新的提交，合并过来后，git会认为和本地开发分支不一样，增加冲突可能性，更不知道代码提交顺序性，造成许多诡异现象。