プルリクエストとマージリクエストと。

short answer

プルリクエストとマージリクエストに違いはありません。 同等の機能が別の呼び方をされているだけです。

名前の由来を考えてみる

名前の由来を考えてみるのも面白いと思うんです。 ここに書いているのは私の予想ですが、大外しはしていないはず。 仮に違ったとしても別に良くて、名前の由来を考えてみることは、名付けのいい訓練になります。なるはず。たぶん。

こんな感じ。たぶんpullは使われてない。

プルリクエスト、通称プルリクは元々GitHubの言葉です。Gitの機能ではありません。 テキストではPRと略されることもあるけど、ピーアールって読むと何を宣伝したいんだろう（Public Relationsとは意味変わっちゃってますね）ってなるからか、発音はプルリクなことが多いと思います。

Gitのpullはfetch+mergeなのだけど、このGitHubでForkしたリポジトリがフォーク元に対してpullを要求するのがプルリクエストと言う名付けの元。ちなみにForkはGitの機能でもGitHubの造語でもなく、元々OSS界隈で使われてた言葉。

GitHubは重々しく考えられていたForkを軽くできることに注力して、そのためにForkしたリポジトリからのフィードバックを扱いやすくすることを重視した結果、プルリクエストと言う名前を全面に出すことにしたんだと思います。 pullがボタン一発でできるならForkもしやすい……そんな感じでしょうかね。 なんのためにForkを軽くしたかったか、とかも妄想していくのも楽しいです。プルリクエストって名前からボトムアップでビジョンにたどり着けるかって感じで。

で、pullのfetchは裏で走れば十分で、ユーザーに重視されるのはmergeの方。 単なるmergeをプルリクエストで扱うのは機能的に問題ないし、ユーザーとしても分ける必要はありません。 なので同じリポジトリ内の単なるmergeもプルリクエストで扱われています。

Gitの文脈で捉えるとmergeなの？pullなの？ってなりそうなボタン

GitLabだとマージリクエスト。これはForkが重視されていないからだと思う。 fetchが要らないなら機能的にはこれが正しいと思います。 機能を重視してのネーミングだとしたら、fetchが必要なものもマージリクエストで扱うので、これはこれでどうなんだろうとなります。 操作として区別する必要のない 歴史的経緯は知りませんが（調べたらわかる話ですが）、Forkを後からできるようにしたのか、元々Forkを重視していなかった、とかでしょうかね。

Backlogだとプルリクエスト。 BacklogはクローズなリポジトリでそもそもForkは扱わないけれど、これは機能よりもよく知られてる言葉を採用したんだと思います。 マージリクエストよりもプルリクエストの方が知名度はありますしね。

他のGitサーバー（って呼び方でいいのかな）も、作成された時期や思想によってどちらかの名前がついていると思います。他の名前もあるのかもしれませんが、知りません。patchを押し出した名前があっても不思議ではないんだけど。

同等の機能に異なる名前がついているのは面白いのですが、混乱している方もいらっしゃるわけで、自身の知っている方の言葉で押し通している方（GitLabを使ってるのにプルリクと言い続けるとか）もあり、なんと言うか。そこまで悪影響を与えるものではないのですが、名前を重視する派を自称する身としてはちょっと悩ましいところですね。

どうでもいいんですが、マージリクエストがマジリクと略されてるのはみたことはありません。 マジなリクエストとか面白そうなんだけど、意味はわからないので使われなくていいと思います。 なおMRと略されることもありますが、この略称はの脳内第一候補はMedical Representativeになるので、ちょっと戸惑ってしまう私です。

pullだのmergeだのってそもそもなんだって方へ

いちばんやさしいGit&GitHubの教本 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

レビューさせてもらった本です。