`Github` 上的 `pull request` 與 `Git` 的 `pull` 有關係？

Question

之前用 SAE 的時候學了點 svn，後來發現還是 Git 先進，再後來就把註冊許久不用的 Github 帳號拿出來很迷惑鼓，結果對 評估者很迷惑 Update:

[上一秒] pull 不是拉麼？怎麼地想也感覺是 push request 才對。

[下一秒] 哦！對作者來說是 pull 。 。 。

那就是兩者一點都不搭邊咯，一個是

CLI

的命令，一個是 Github 上概念性的東西。

Answer 1

我來說的更清楚一些吧，之前的答案和討論都似是而非，並未直指真相。

Github 上的 pull request 和 git pull 并非完全没有关系，不过和它关系最近的则是另外一个命令 git request-pull。

先說概念上的解釋。可能多數人（包括題主）會這樣理解 pull request：

我，提交一個請求，把我的改動整合到 upstream（上游，通常代表你的 fork 的來源）去

這麼一來，感覺應該是 push request 最貼切，因為這個動作完全是我主動的嘛！

然而這樣理解忽略了一個前提：你有往 upstream 去 push 的權限嗎？ 換言之，你能直接寫 upstream 嗎？

這要分兩種情況（對應了兩種基於 Git 的工作流程）：

1. 有權限－那麼你完全沒必要 fork & pull request，既然作者給了你權限，你就直接 clone 下來當作自己的 repo 去操作就好了，何必多此一舉？
2. 沒權限－既然沒權限，何來 push request 一說？

歸根究底，產生這誤會的緣由在於不完全清楚 pull request 工作流程的工作原理。對於 pull request 動作的正確描述應該是這樣的：

我，發起一個請求（以Github 來說就是一個HTTP 請求呼叫對應API，然後由Github 在後端執行git request-pull，詳見後文），這個請求（HTTP request 裡的request）是請求（pull request 裡的request）上游的作者去拉取（pull request 裡的pull）來自於我的fork 裡的變更。

這才是正確的理解。

最後來說說 git request-pull。当你做出 pull request 请求的时候，其实背后执行的是 git request-pull。當你做出

pull request

請求的時候，其實背後執行的是 這個子指令。這個子命令的（主要）簽名如下：

bash$ git request-pull <start> <url> [<end>]

這條指令產生了一個摘要，其中包含了變更記錄（以 commit 為單位）和用於抓取這些變更的位址。摘要以固定格式的純文字輸出到 stdout 去，你可以重新導向然後寫程式做後續處理。 Github 就是這樣來分析每一個

pull request 的，因此能看到對應的 commit，時間，作者等等資訊。 git pull 去指定地址（包含在 git request-pull上游作者在收到

pull request

之後若選擇接受，Github 則呼叫 git pull 去指定位址（包含在

產生的資訊裡）拉取程式碼。上游作者自然有寫入 upstream repo 的權限，於是一個完整的流程得以實現。 🎜 🎜建議去閱讀一下 Git 官方手冊，特別是這一章：分散式 Git - 為專案作貢獻，讀完之後我包你受益匪淺。 🎜

Answer 2

公開的庫對吧，你對這個庫pull你的修改，然後這個庫的作者就可以看到你的請求，並決定是否給你合併到他的本來的庫上。