什么是Pull Request？

PR 的全稱是Pull Request，經常用 Github 的同學對這個肯定很熟悉了。Github 聚集了4000萬開發者，過億的開源項目，如果想給別人的開源倉庫貢獻代碼，通常是先 fork 別人的項目，然后本地修改完成提交到自己的個人 fork 倉庫，最后提交 PR 等待別人合入你的代碼。

Github 的工作流：

   

我們重點看一下第6步，小明寫完代碼了想合入到原作者的倉庫，新建了一個“pull request”，拉請求？這明明是推啊，小明將自己的修改推到原作者的倉，感覺叫“push request”比較合適吧。

既然 Github 堅持叫“pull request”，我們試著理解一下它的思路，小明寫完代碼了心里肯定是在想：原作者大神，我改了點東西，你快把我的修改拉回去吧。站在原作者的角度思考，叫pull request好像也說得過去，每天有大量的人從我這里 fork 代碼走，我只會拉取我感興趣的代碼回來。

我好像把自己說服了。

什么是 Merge Request？

MR 的全稱是 Merge Request，相信玩過 Gitlab 的同學都知道這個。

插播一下，Github這么好用了為什么還有人玩 Gitlab，這就要幾年前說起了。在微軟沒有收購 Github 之前，Github 上面所有的項目必須是公開的，也就是說自己很渣的代碼也必須要公開，不能藏著噎著。但是在一些小的公司或者創業團隊，代碼這種核心資產是不希望被公開，他們迫切需要私密倉這種需求，所以很多人都選擇了 Gitlab。當然后面 Github 也放開了私有倉庫，這是后話了。

   

團隊中每個人都從遠程倉庫 develop 分支拉取代碼，本地基于 develop 分支新建特性分支，修改完代碼將特性分支推到遠程倉，緊接著新建 Merge Request 期望將自己的特性分支合入 develop 分支。

從上面這個流程來看Merge Request 就是將自己的特性分支合入到主干分支。

Pull Request VS 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 確實讓人難以理解，我們去各大網站看看用戶的聲音。

   

      

從國外到國內都有大量的用戶對這個名字不理解，明明是提交提交代碼，為什么是 pull request，有些人甚至懷疑是名字打錯了。

如果讓我來給 Github 取名字，我可能會取：

• push request 推請求
• merge request 合并請求