githubのpull request はgitlabのようにmerge requestにした方がしっくりくると思う

ソフトウェア開発において，コード変更の提案と統合は重要なプロセスだ．GitHubとGitLabという二大プラットフォームは，この機能に異なる名称を与えている．なぜGitHubは「プルリクエスト」，GitLabは「マージリクエスト」と呼ぶのか．この違いの背景を詳しく探ってみよう．

Githubのpull request
![スクリーンショット 2024-09-10 21.50.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/96c08211-516b-4dc1-dba3-65ee82b3831f.png)
と
Gitlabのmerge request
![スクリーンショット 2024-09-10 21.52.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/b11e0bda-69b6-f24e-4291-88ec1c48ae24.png)
どっちも同じイラストで内容も同じである．

> **筆者小噺**
> githubのpull requestをみんなPRって言ってるけど何を宣伝してんだよ
> じゃあgitlabはMR(複合現実感)やないか

> 今回の記事は考察中心なので思ったことはコメントに書いてほしいです．

gitのことを知るなら以下の記事から
**git/ghコマンドチートシート**

https://qiita.com/JavaLangRuntimeException/items/6b46551f56e0def76eba

**プルリクエスト/マークダウン記法チートシート**

https://qiita.com/JavaLangRuntimeException/items/329eb92a47a07ff4dde8

# プルリクエスト，マージリクエストって何
まず，マージという操作がある．
マージとは作成したブランチでの作業を他のブランチの統合する作業のことである．
リモートリポジトリでは直接マージをすることはなく，githubではプルリクエスト/gitlabではマージリクエストというものを作成し，マージするための要求を行う．そして，PR/MRがレビューされ，承認された後，そのブランチの変更はメインブランチ（または指定されたブランチ）にマージすることとなる．マージをすると基本マージコミットが作成され，そのコミットをマージ先のブランチにてプッシュすることで統合(マージ)が完了する．

ローカルブランチではmergeコマンド(後述)であるブランチの変更点(作業)を他のブランチに統合する．
例えばfeatureブランチはdevelopmentブランチに向けてマージをし，developmentブランチはmainブランチに向けてマージする．
![スクリーンショット 2024-05-03 3.04.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/883b9a90-b7ff-22b3-d5d1-4ab8146e7ae8.png)


# GitHubのプルリクエストの由来の考察
![スクリーンショット 2024-09-10 22.21.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/15bd55eb-3434-8e55-dbbf-da965d0b3c91.png)


![スクリーンショット 2024-09-10 21.50.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/96c08211-516b-4dc1-dba3-65ee82b3831f.png)
GitHubが「プルリクエスト」を選んだ理由は複数考えられる．

**1. Gitの操作との関連性**
   Gitの「pull」操作は，リモートリポジトリの変更をローカルに取り込む．GitHubは，この概念を拡張し，「変更を提案し，プロジェクトに取り込んでもらう」という意味合いを込めた．

**オープンソースコミュニティへの配慮**
   GitHubの初期の主要ターゲットはオープンソースプロジェクトだった．「プル」という言葉は，「コントリビューションを引き寄せる」というニュアンスがあり，オープンな協業を促進する雰囲気を醸成するのに適していた．

**心理的障壁の低減**
   「プル」は「引っ張る」という意味があり，変更を提案する側が主体的に行動するイメージを与える．これにより，コントリビューターが気軽に変更を提案しやすい雰囲気を作り出した．

**既存の概念との差別化**
   当時，「パッチの適用」という概念が一般的だった．GitHubは新しい協業モデルを提案するため，意図的に異なる用語を選んだ可能性がある．

# GitLabのマージリクエストの由来の考察
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/ca3023c3-bcd4-afd7-8d0d-efcd2cd30f10.png)

![スクリーンショット 2024-09-10 21.52.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/b11e0bda-69b6-f24e-4291-88ec1c48ae24.png)
                GitLabが「マージリクエスト」を選んだ理由も，いくつか考えられる

**機能の本質的な描写**
   この機能の核心は，二つのブランチをマージすることだ．「マージリクエスト」は，この操作をより直接的に表現している．

**企業ユーザーへの配慮**
   GitLabは当初から企業内での使用を主なターゲットとしていた．企業環境では，技術的に正確な用語がより重視される傾向がある．

**既存のGit用語との整合性**
   Gitでは「merge」という操作が基本的であり，開発者にとってなじみ深い．GitLabはこの既存の概念を活用した．

**プロセスの明確化**
   「マージ」という言葉を使うことで，この操作の最終目的（ブランチの統合）を明確に示している．

# 名称の違いが示唆するもの

この名称の違いは，両プラットフォームの哲学や戦略の違いを反映していると考える．

**ターゲットユーザーの違い**
   GitHubはオープンソースコミュニティを，GitLabは企業ユーザーを主なターゲットとしていた．

**協業モデルの違い**
   GitHubは「プル」モデルで外部からの貢献を促進，GitLabは「マージ」モデルで内部での統合を重視．

**ユーザー体験の設計**
   GitHubは心理的障壁を下げることを，GitLabは操作の明確さを重視した．

# 筆者の意見とまとめ
githubのプルリクエスト，ってなんかいまいちしっくりくないんですよね．私個人ではマージリクエストの方がしっくりくる？(と思っていたのでこの記事を書いたのですが)
今回githubの誕生背景を調べて，由来を考察するとプルリクエストという名前にした理由も納得のいくものだった．．．が，初めてgithubを触った際にプルリクエストだと何をするのかがよく分かりにくいのでマージリクエストであってほしいなあと思います．

> 今ではプルリクエストという名前に慣れすぎて逆に落ち着いてます(笑)

結論として「プルリクエスト」と「マージリクエスト」の名称の違いは，単なる言葉の選択以上の意味を持つがそれらはそれぞれのプラットフォームの歴史，対象ユーザー，協業モデルの違いを反映していると思います．
この事例は，ソフトウェア開発でも同じことが起きていて，命名の重要性と，同時にその難しさを感じさせました．同じ機能に対して異なる名称が存在することは，技術の進化と多様性の表れでもあり，開発コミュニティの豊かさを示すものだと言えるのではないだろうか．