short answer
プルリクエストとマージリクエストに違いはありません。 同等の機能が別の呼び方をされているだけです。
名前の由来を考えてみる
名前の由来を考えてみるのも面白いと思うんです。 ここに書いているのは私の予想ですが、大外しはしていないはず。 仮に違ったとしても別に良くて、名前の由来を考えてみることは、名付けのいい訓練になります。なるはず。たぶん。
プルリクエスト、通称プルリクは元々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
もプルリクエストで扱われています。
GitLabだとマージリクエスト。これはForkが重視されていないからだと思う。
fetch
が要らないなら機能的にはこれが正しいと思います。
機能を重視してのネーミングだとしたら、fetch
が必要なものもマージリクエストで扱うので、これはこれでどうなんだろうとなります。
操作として区別する必要のない
歴史的経緯は知りませんが(調べたらわかる話ですが)、Forkを後からできるようにしたのか、元々Forkを重視していなかった、とかでしょうかね。
Backlogだとプルリクエスト。 BacklogはクローズなリポジトリでそもそもForkは扱わないけれど、これは機能よりもよく知られてる言葉を採用したんだと思います。 マージリクエストよりもプルリクエストの方が知名度はありますしね。
他のGitサーバー(って呼び方でいいのかな)も、作成された時期や思想によってどちらかの名前がついていると思います。他の名前もあるのかもしれませんが、知りません。patch
を押し出した名前があっても不思議ではないんだけど。
同等の機能に異なる名前がついているのは面白いのですが、混乱している方もいらっしゃるわけで、自身の知っている方の言葉で押し通している方(GitLabを使ってるのにプルリクと言い続けるとか)もあり、なんと言うか。そこまで悪影響を与えるものではないのですが、名前を重視する派を自称する身としてはちょっと悩ましいところですね。
どうでもいいんですが、マージリクエストがマジリクと略されてるのはみたことはありません。 マジなリクエストとか面白そうなんだけど、意味はわからないので使われなくていいと思います。 なおMRと略されることもありますが、この略称はの脳内第一候補はMedical Representativeになるので、ちょっと戸惑ってしまう私です。
pullだのmergeだのってそもそもなんだって方へ
レビューさせてもらった本です。