之前用 SAE 的时候学了点 svn，后来发现还是 Git 先进，再后来就把注册许久不用的 Github 账号拿出来捣鼓，结果对 pull request 很迷惑。
SAE
svn
Git
Github
pull request
Update: [上一秒] pull 不是拉么？怎么地想也感觉是 push request 才对。 [下一秒] 哦！对作者来说是 pull 。。。
那就是两者一点都不搭边咯，一个是 CLI 的命令，一个是 Github 上概念性的东西。
CLI
学习是最好的投资！
もっとはっきり言っておきますが、これまでの回答と議論は疑わしいものであり、真実を示したものではありません。
#pull request は git pull とまったく無関係ではありませんが、これに最も近い関係があるのは別のコマンド git request-pull です。 git pull 并非完全没有关系，不过和它关系最近的则是另外一个命令 git request-pull。
git pull
git request-pull
先说概念上的解释。可能多数人（包括题主）会这样理解 pull request：
我，提交一个请求，把我的改动整合到 upstream（上游，通常代表你的 fork 的来源）去
这么一来，感觉应该是 push request 最贴切，因为这个动作完全是我主动的嘛！
然而这样理解忽略了一个前提：你有往 upstream 去 push 的权限吗？换言之，你能直接写 upstream 吗？
这要分两种情况（对应了两种基于 Git 的工作流）：
归根结底，产生这一误会的缘由在于不完全清楚 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 这个子命令。这个子命令的（主要）签名如下：
bash$ git request-pull <start> <url> [<end>]
bash
$ git request-pull <start> <url> [<end>]
这条命令生成了一个摘要，其中包含了变更记录（以 commit 为单位）和用于抓取这些变更的地址。摘要以固定格式的纯文本输出到 stdout 去，你可以重定向然后编写代码做后续处理。Github 就是这样来分析每一个 pull request 的，因此能看到对应的 commit，时间，作者等等信息。
上游作者在收到 pull request 之后若选择接受，Github 则调用 git pull 去指定地址（包含在 git request-pull まずは概念的な説明からお話しましょう。おそらく、ほとんどの人（件名を含む）はこのように理解できるでしょう
：
git request-pull に含まれる) を指定します。 ) を使用してコードをプルします。上流の作成者は当然、上流のリポジトリへの書き込み権限を持っているため、完全なプロセスを実現できます。 #🎜🎜# #🎜🎜# 公式 Git マニュアル、特にこの章「分散 Git - プロジェクトへの貢献」を読むことをお勧めします。読んだ後は大きなメリットがあることを保証します。 #🎜🎜#
これは公開ライブラリですよね? このライブラリに変更をプルすると、このライブラリの作成者はあなたのリクエストを見て、それを元のライブラリにマージするかどうかを決定できます。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
もっとはっきり言っておきますが、これまでの回答と議論は疑わしいものであり、真実を示したものではありません。
Github の#pull request は
git pullとまったく無関係ではありませんが、これに最も近い関係があるのは別のコマンドgit request-pullです。git pull并非完全没有关系，不过和它关系最近的则是另外一个命令git request-pull。先说概念上的解释。可能多数人（包括题主）会这样理解 pull request：
这么一来，感觉应该是 push request 最贴切，因为这个动作完全是我主动的嘛！
然而这样理解忽略了一个前提：你有往 upstream 去 push 的权限吗？换言之，你能直接写 upstream 吗？
这要分两种情况（对应了两种基于 Git 的工作流）：
归根结底，产生这一误会的缘由在于不完全清楚 pull request 工作流的工作原理。对于 pull request 动作的正确描述应该是这样的：
这才是正确的理解。
最后来说说
git request-pull。当你做出 pull request 请求的时候，其实背后执行的是git request-pull这个子命令。这个子命令的（主要）签名如下：这条命令生成了一个摘要，其中包含了变更记录（以 commit 为单位）和用于抓取这些变更的地址。摘要以固定格式的纯文本输出到 stdout 去，你可以重定向然后编写代码做后续处理。Github 就是这样来分析每一个 pull request 的，因此能看到对应的 commit，时间，作者等等信息。
上游作者在收到 pull request 之后若选择接受，Github 则调用
プルリクエストgit pull去指定地址（包含在git request-pullまずは概念的な説明からお話しましょう。おそらく、ほとんどの人（件名を含む）はこのように理解できるでしょう：
#🎜🎜#変更をアップストリーム (通常はフォークのソースを表す) に統合するためのプル リクエストを #🎜🎜# に送信します #🎜🎜#この場合は#🎜🎜#プッシュリクエスト#🎜🎜#が一番適切な気がします、なぜならこの行動は完全に私の主導権だからです！ #🎜🎜# #🎜🎜# ただし、この理解は前提を無視しています:上流にプッシュする権限を持っていますか? つまり、上流に直接書けるのか？ #🎜🎜# #🎜🎜#これは 2 つの状況 (2 つの Git ベースのワークフローに対応) に分類できます。 #🎜🎜#git request-pullを実行します。詳細については以下を参照してください)。 # 🎜🎜# (HTTP リクエストでのリクエスト) #🎜🎜# はリクエストです #🎜🎜# (プルリクエストでのリクエスト) #🎜🎜# 上流の作者がプルします #🎜🎜# (プルリクエストでのプル) #🎜 🎜#私のフォークの変更から来ています。 #🎜🎜# #🎜🎜#これが正しい理解です。 #🎜🎜# #🎜🎜#最後に、git request-pullについて話しましょう。 #🎜🎜#pull request#🎜🎜# リクエストを行うと、実際にはgit request-pullサブコマンドがバックグラウンドで実行されます。このサブコマンドの (メイン) シグネチャは次のとおりです: #🎜🎜# リーリー #🎜🎜#このコマンドは、変更レコード (コミット) とこれらの変更をフェッチするために使用されるアドレスを含む概要を生成します。概要は固定形式のプレーン テキストで stdout に出力され、これをリダイレクトして後続の処理用のコードを作成できます。これは、Github が各 #🎜🎜#pull request#🎜🎜# を分析する方法であり、対応するコミット、時間、作成者、その他の情報を確認できます。 #🎜🎜# #🎜🎜# 上流の作成者が #🎜🎜#pull request#🎜🎜# を受け取った後に受け入れることを選択した場合、Github はgit pullを呼び出してアドレス (git request-pull に含まれる) を指定します。 ) を使用してコードをプルします。上流の作成者は当然、上流のリポジトリへの書き込み権限を持っているため、完全なプロセスを実現できます。 #🎜🎜# #🎜🎜# 公式 Git マニュアル、特にこの章「分散 Git - プロジェクトへの貢献」を読むことをお勧めします。読んだ後は大きなメリットがあることを保証します。 #🎜🎜#これは公開ライブラリですよね? このライブラリに変更をプルすると、このライブラリの作成者はあなたのリクエストを見て、それを元のライブラリにマージするかどうかを決定できます。