マージリクエストって何?変更を取り込む「お願い」の仕組み

マージリクエストは「この変更、本体に入れていいですか?」の申請書

マージリクエスト(Merge Request、略してMR)は、バージョン管理システムのGitを使った開発で、自分が作った変更を本体のコードに取り込んでもらうための「お願い」です。GitLabで使われている呼び方で、GitHubでは同じものを「プルリクエスト(Pull Request、PR)」と呼びます。名前が違うだけで、やっていることはほぼ同じだと思ってもらって大丈夫です。

いきなり「マージ」と言われてもピンと来ないかもしれません。Gitでは、作業を進めるときに本体のコード(よくmainやmasterと呼ばれます)から枝分かれした「ブランチ」という作業用のコピーを作ります。そのブランチで変更を加えて、完成したら本体に合流させる。この合流作業がマージです。マージリクエストは、その合流を実行する前に「レビューしてください、問題なければ合流させてください」と伝えるための仕組みです。

社内の書類申請に例えると

会社で経費を精算するところを想像してみてください。領収書を集めて申請書を書き、上司に提出します。上司は中身を確認して、おかしなところがあれば「この項目、用途が分かりにくいので書き直して」とコメントを返す。問題なければ承認印を押して、経理に回って処理が完了します。

マージリクエストもこれとよく似ています。

• 申請書を書く = ブランチで変更を加えて、マージリクエストを作成する
• 上司が中身を確認する = チームメンバーがコードレビューをする
• 差し戻しコメント = 「この書き方だとバグりそう」などのレビューコメント
• 承認印 = Approve(承認)
• 経理で処理完了 = マージ実行、本体に変更が取り込まれる

経費精算で勝手に会社の口座からお金を引き出す人はいないですよね。コードも同じで、いきなり本体を書き換えるのではなく、一度確認を挟むことで事故を防いでいます。

マージリクエストの流れ

ここで大事なのは、マージリクエストが「作って終わり」ではないことです。レビューコメントが付いたら、同じブランチに追加でコミットを積みます。するとマージリクエストの中身が自動で更新されるので、新しくリクエストを作り直す必要はありません。一度出した申請書を、差し替えずにその場で修正していくイメージです。

何がうれしいのか

正直なところ、一人で開発しているうちは「わざわざ面倒だな」と感じると思います。自分のコードを自分でレビューしても仕方がない、と。でも複数人で開発し始めると、ありがたみが一気に分かります。

まず、他人の目が入ることでバグや設計の不味さに気づけます。書いた本人は自分のコードが正しいと思い込んでいるので、第三者の視点はかなり効きます。それから、「誰がいつ、なぜこの変更を入れたのか」が記録として残ります。半年後に「このコード何だ?」となったとき、マージリクエストの説明文とレビューのやり取りを遡れるのは本当に助かります。

さらに、マージリクエストをきっかけに自動テストを走らせる仕組みを組み合わせているチームも多いです。テストが落ちていたらマージできないようにしておけば、壊れたコードが本体に混ざるのを機械的に防げます。

プルリクエストとの違い

呼び方	主に使われる場所
マージリクエスト(MR)	GitLab
プルリクエスト(PR)	GitHub

チームによって呼び方が混ざっていることもあります。会話で「PR出しといて」と言われたのにGitLabを使っている、みたいな状況はよくあるので、同じものを指していると理解しておけば困りません。

最初のうちに気をつけたいこと

一番やりがちなのが、大量の変更を一つのマージリクエストに詰め込んでしまうことです。レビューする側からすると、500行の差分を渡されると集中力が持たず、結局ざっと眺めて「LGTM(見た感じ良さそう)」で通してしまいがちです。それではレビューの意味が薄れます。できるだけ小さく、一つの目的に絞って出すのがコツです。

もう一つは、説明文を空っぽのまま出すこと。「何を」変えたかは差分を見れば分かりますが、「なぜ」変えたかは本人しか知りません。一行でもいいので背景を書いておくと、レビュアーの理解が段違いに速くなります。