作者：知乎用户
链接：https://www.zhihu.com/question/21682976/answer/79489643
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
我尝试用类比的方法来解释一下 pull reqeust。想想我们中学考试，老师改卷的场景吧。你做的试卷就像仓库，你的试卷肯定会有很多错误，就相当于程序里的 bug。老师把你的试卷拿过来，相当于先 fork。在你的卷子上做一些修改批注，相当于 git commit。最后把改好的试卷给你，相当于发 pull request，你拿到试卷重新改正错误，相当于 merge。
当你想更正别人仓库里的错误时，要走一个流程：
至此，整个 pull request 的过程就结束了。
理解了 pull request 的含义和流程，具体操作也就简单了。以 Github 排名最高的
https://github.com/twbs/bootstrap
为例说明。
1. 先点击 fork 仓库，项目现在就在你的账号下了
2. 在你自己的机器上 git clone 这个仓库，切换分支（也可以在 master 下），做一些修改。
~ git clone https://github.com/beepony/bootstrap.git
~ cd bootstrap
~ git checkout -b test-pr
~ git add . && git commit -m "test-pr"
~ git push origin test-pr3. 完成修改之后，回到 test-pr 分支，点击旁边绿色的 Compare & pull request 按钮
4. 添加一些注释信息，确认提交
5. 仓库作者看到，你提的确实是对的，就会 merge，合并到他的项目中
以上就是 pull reqesut 的整个流程，希望对你有帮助～
我从单纯的语言学角度解释一下为什么“pull request”这个词组这么令人费解。
先说正确的理解：pull request是一个request，它的目的是让别人pull你的东西。
然而pull和request两个名词直接相连构成偏正短语，二者之间具体是什么关系是不确定的。
思考：water hose, rubber hose, fire hose, garden hose 这四个短语中，两个词之间分别是什么关系？
我第一次看到pull request这个词组的时候，误以为这个request的目的是请求别人允许自己pull别人的东西。
另外，pull和request还都有动词义，放到一起的时候，还可能被误解成动宾短语（pull作动词，request作名词）。
英语中很多单词有多种词性，另外对一串名词直接相连构成词组的句法又比较宽容，这两个性质容易被滥用，造成沟通上的不便。
恰好汉语也具有这两个特点——你把上文中的“pull request”都换成“拉取请求”，看看是不是依然成立？
当然，熟悉了GitHub的工作流程后，你可能就不再感觉pull request这个词组有歧义或是费解了。
这是专业知识消除歧义的典型例子。
使用过git的应该都知道git pull，这个命名相当于连续执行两个命令git fetch然后git merge。所以，pull request的意思就是一个“请求”（request），请对方做一个git fetch拿到request中的代码commits，然后git merge一下到某个分支上。
pull request简称PR，是github的概念，不是git的概念，所以也不是立刻出结果的，需要有人去同意完成这个PR，当然同意完成PR的可以是自己，也可以拒绝PR。
现实项目中，即使自己对某个repo的特定分枝有写入权限，也可以提PR来修改，因为这是code review的一种方式，让团队的其他人看一看改的咋样。
GitHub上这里做了专门的解释（页面有交互），浅显易懂。
Understanding the GitHub Flow · GitHub Guides
可以从字面上理解：
Request是请求的意思；Pull是从主干（Master）的角度来说的，可以理解为把主干的分支的代码拉（Pull）回主干，也就是代码合并的意思。
所以合起来理解，就是『请求代码合并』
在团队中我承担了Committer 的责任，也就是帮同事们检视代码（Code Review）和合入代码，经常听到有同事在群里喊：“大佬，帮我合个 PR”，“大佬，我刚提交了一个 MR，帮忙合一下，急着出补丁”。我有点懵了，PR 和 MR 到底哪个才是正确的，这两个到底有什么区别，我决定先搞清楚这两个概念再合入他们的代码。[手动滑稽]
PR 的全称是Pull Request，经常用 Github 的同学对这个肯定很熟悉了。Github 聚集了4000万开发者，过亿的开源项目，如果想给别人的开源仓库贡献代码，通常是先 fork 别人的项目，然后本地修改完成提交到自己的个人 fork 仓库，最后提交 PR 等待别人合入你的代码。
Github 的工作流：
fork 工作流
我们重点看一下第6步，小明写完代码了想合入到原作者的仓库，新建了一个“pull request”，拉请求？这明明是推啊，小明将自己的修改推到原作者的仓，感觉叫“push request”比较合适吧。
既然 Github 坚持叫“pull request”，我们试着理解一下它的思路，小明写完代码了心里肯定是在想：原作者大神，我改了点东西，你快把我的修改拉回去吧。站在原作者的角度思考，叫pull request好像也说得过去，每天有大量的人从我这里 fork 代码走，我只会拉取我感兴趣的代码回来。
我好像把自己说服了。
MR 的全称是 Merge Request，相信玩过 Gitlab 的同学都知道这个。
插播一下，Github这么好用了为什么还有人玩 Gitlab，这就要几年前说起了。在微软没有收购 Github 之前，Github 上面所有的项目必须是公开的，也就是说自己很渣的代码也必须要公开，不能藏着噎着。但是在一些小的公司或者创业团队，代码这种核心资产是不希望被公开，他们迫切需要私密仓这种需求，所以很多人都选择了 Gitlab。当然后面 Github 也放开了私有仓库，这是后话了。
merge 工作流
团队中每个人都从远程仓库 develop 分支拉取代码，本地基于 develop 分支新建特性分支，修改完代码将特性分支推到远程仓，紧接着新建 Merge Request 期望将自己的特性分支合入 develop 分支。
从上面这个流程来看Merge Request 就是将自己的特性分支合入到主干分支。
总结一下上面两个例子。
Github 是玩 fork 模式的，开发者提交自己的代码新建 Pull Request，请求原作者：“把我的代码拉回去吧”。
Gitlab 是玩分支模式的，开发者提交自己的代码新建 Merge Request，想将自己的特性分支合并到主干。
上面总结的好像很有道理，但是不要忘了，Github 也可以玩分支模式，Gitlab 也可以玩 fork 模式，更令人无语的是：
Github 上合并分支还是叫 Pull Request；Gitlab 上fork 模式也是叫 Merge Request；
不行，这种答案我没法接受，去 stackoverflow上搜一些大家是怎么理解的。果然有一个帖子很火：
Pull request vs Merge request
有一个回答摘取了 Gitlab 的官方解释：
Merge or pull requests are created in a git management application and ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name pull request since the first manual action would be to pull the feature branch. Tools such as GitLab and Gitorious choose the name merge request since that is the final action that is requested of the assignee. In this article we'll refer to them as merge requests.
翻译过来简单理解就是：这两个没有本质区别，站在不同立场说法不一样而已。
好了，官方已经盖棺定论了，这两个就是一个东西，不要纠结啦~
对于初学者来说，Github 的 pull request 确实让人难以理解，我们去各大网站看看用户的声音。
StackOverflow
从国外到国内都有大量的用户对这个名字不理解，明明是提交提交代码，为什么是 pull request，有些人甚至怀疑是名字打错了。
如果让我来给 Github 取名字，我可能会取：
想多了，不会有如果。[嘿哈]
Pull Request 和Merge Request 本质上都是合入代码，只是站在不同角度有不同的说法而已，因此在学习和工作中无论用哪一个都没有问题。