git pull根据不同的配置，可等于fetch + merge或fetch + rebase。要理解它们的区别，首先需要明白git架构，它是分布式版本管理系统。画了张图，不仅仅涉及到git fetch和git pull，对整体理解也会很有帮助。如下：
上图展示了git的整体架构，以及和各部分相关的主要命令，先说明下其中涉及的各部分：
工作区(working directory)，简言之就是你工作的区域。对于git而言，就是的本地工作目录。工作区的内容会包含提交到暂存区和版本库(当前提交点)的内容，同时也包含自己的修改内容。
暂存区(stage area, 又称为索引区index)，是git中一个非常重要的概念。是我们把修改提交版本库前的一个过渡阶段。查看GIT自带帮助手册的时候，通常以index来表示暂存区。在工作目录下有一个.git的目录，里面有个index文件，存储着关于暂存区的内容。git add命令将工作区内容添加到暂存区。
本地仓库(local repository)，版本控制系统的仓库，存在于本地。当执行git commit命令后，会将暂存区内容提交到仓库之中。在工作区下面有.git的目录，这个目录下的内容不属于工作区，里面便是仓库的数据信息，暂存区相关内容也在其中。这里也可以使用merge或rebase将远程仓库副本合并到本地仓库。图中的只有merge，注意这里也可以使用rebase。
远程版本库(remote repository)，与本地仓库概念基本一致，不同之处在于一个存在远程，可用于远程协作，一个却是存在于本地。通过push/pull可实现本地与远程的交互；
远程仓库副本，可以理解为存在于本地的远程仓库缓存。如需更新，可通过git fetch/pull命令获取远程仓库内容。使用fech获取时，并未合并到本地仓库，此时可使用git merge实现远程仓库副本与本地仓库的合并。git pull 根据配置的不同，可为git fetch + git merge 或 git fetch + git rebase。rebase和merge的区别可以自己去网上找些资料了解下。
看到这里，不仅清楚了git fetch与git pull。而且我们使用每个命令时，也能清楚的明白此时git做了什么工作。
pull request
pull request简称PR，是github的概念，不是git的概念，所以也不是立刻出结果的，需要有人去同意完成这个PR，当然同意完成PR的可以是自己，也可以拒绝PR。比如Linux内核项目，直接给linus发邮件，标题就是Pull Request。邮件里写上git的url和你新增的feature或fix的bug。如果linus觉得ok，就会根据给出的git url去git pull。
解释一：
有一个仓库，叫Repo A。你如果要往里贡献代码，首先要Fork这个Repo，于是在你的Github账号下有了一个Repo A2。然后你在这个A2下工作，Commit，push等。然后你希望原始仓库Repo A合并你的工作，你可以在Github上发起一个Pull Request，意思是请求Repo A的所有者从你的A2合并分支。如果被审核通过并正式合并，这样你就为项目A做贡献了。
解释二：
我尝试用类比的方法来解释一下 pull reqeust。想想我们中学考试，老师改卷的场景吧。你做的试卷就像仓库，你的试卷肯定会有很多错误，就相当于程序里的 bug。老师把你的试卷拿过来，相当于先 fork。在你的卷子上做一些修改批注，相当于 git commit。最后把改好的试卷给你，相当于发 pull request，你拿到试卷重新改正错误，相当于 merge。
当你想更正别人仓库里的错误时，要走一个流程：
- 先fork别人的仓库，相当于拷贝一份，因为不会有人直接让你改修原仓库的
- clone到本地分支，做一些bug fix
- 发起pull request给原仓库，让他看到你修改的bug
- 原仓库review这个bug，如果是正确的话，就会merge到他自己的项目中
至此，整个pull request的过程就结束了。
小结：
1.git fetch并没更改本地仓库的代码，只是拉取了远程commit数据，将远程仓库的commit id更新为latest。
2.可以尝试查看.git文件夹：./git/refs里面有三个文件夹：heads、remotes、tags。heads和remotes分别记录的就是本地和远程不同仓库的最新commit id。
3.fetch改变的是remotes里面相应分支的commit id。