Merge Request (MR): その概要、作成方法、レビュープロセス

Merge Request (MR)とは？

Merge Request (MR) — あるGitブランチから別へ変更を統合するリクエストであり、コードレビューと自動チェックのプロセスを開始します。コンソールを介した直接マージとは異なり、MRは正式な手順を作成します。開発者が変更を説明し、レビュアーを割り当て、CI/CDを起動し、変更適用前にフィードバックを受け取ります。これはGitLabの主要要素ですが、GitHubの同等の仕組みはPull Request (PR)と呼ばれます。

GitLab Documentation, 2026によると、GitLabでは年間8000万以上のMerge Requestsが作成されています。各MRには4つの主要コンポーネントがあります。変更コンテキストを含む説明、コミットの一覧、コードの差分（diff）、議論（ディスカッションスレッド）です。これらの要素の1つでも欠けると、MRは不完全と見なされます。

Merge Request (MR)は3つのタスクを解決します。保護されたブランチ（main、develop）への直接変更を防止し、レビューによる品質管理を提供し、将来の開発者のために議論の履歴を保存します。GitLabでは、MRのステータスがインターフェースに色で表示されます。Draftは灰色、保留中はオレンジ、Approvedは緑、Mergedは紫、Closedは赤です。

用語: MR、PR、CR

Gitプラットフォームによって、Merge Requestの呼び名は異なります。GitLabは“Merge Request” (MR)、GitHubは“Pull Request” (PR)を使用します。GerritのChange Request (CR)も同様です。3つすべてがコードレビューを通じて変更を統合するリクエストという同じプロセスを示しています。用語の選択はプロジェクトで使用されるプラットフォームにのみ依存します。

# 変更を含むブランチを作成する
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# GitLab/GitHub UIまたはCLIからMRを作成できます：
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: GitLabとGitHubの違い

GitLabのMerge RequestとGitHubのPull Requestは、機能的には同一の仕組みで、名前だけが異なります。その違いは歴史に起因します。GitLabは元々GitHubのSelf-Hosted代替として位置づけられ、マージプロセスに“merge request”という用語を選びました。先に立ち上げられたGitHubは、メインブランチに変更を“プル”するリクエストとして“pull request”を使用しました。

GitHub Docs, 2024によると、両方のツールは同じ機能セットをサポートしています。Markdownによる説明、レビュアー割り当て、特定のコード行へのコメント、チェックステータス、条件満たす場合の自動マージです。違いはインターフェースと追加機能に関するものです。

Merge Requestの作成方法: ステップバイステップガイド

Merge Request (MR)の作成は、変更を含むブランチをリモートリポジトリに公開することから始まります。GitLabまたはGitHubにプッシュすると、インターフェースに“Create Merge Request”または“Compare & Pull Request”ボタンが表示されます。開発者は説明を記入し、ターゲットブランチ（通常developまたはmain）を指定し、レビュアーを割り当て、ラベルを添付します。

GitLab Documentation, 2025によると、標準的なMRには72文字以内のタイトル、テンプレート付きの説明、イシューへのリンクが含まれます。説明は「何をしたか」「なぜか」「どうテストしたか」の質問に答える必要があります。GitLabはCloses、Fixes、Resolvesのキーワードによるマージ時の自動イシュー閉鎖をサポートしています。

# .gitlab/merge_request_templates/default.mdテンプレートの例
## What does this MR do?

[変更の概要: 内容と理由]

## How to test

1. 実行する ./gradlew test
2. 確認する LoginActivity をテストトークンで
3. にリグレッションがないことを確認する AuthManager

## Related issues

Closes #142

MRのライフサイクル: DraftからMergedまで

Merge Request (MR)はGitLabで5つのステータスを経ます。最初はDraft（下書き）で、タイトルに“Draft:”プレフィックスが付き、マージをブロックします。準備ができたら開発者がDraftを外し、MRはOpenedステータスに移行します。コードレビューが始まり、CI/CDパイプラインが起動します。

GitLab Docs, 2024によると、Openedステータスではレビュアーがdiffを調べ、コメントを残し、Resolve Threadsを通じて変更を要求します。すべてのスレッドが解決されCI/CDが成功すると、責任者がApproveを設定します。その後、Mergeボタンでマージするか、自動マージ（Auto-merge）を待つことができます。

GitLabは3つの最終ステータスオプションをサポートしています。Merged（正常にマージ）、Closed（機能放棄などでマージせず閉鎖）、Reopened（閉鎖後の再開）です。各ステータスは監査のためにMRアクティビティタイムラインに記録されます。

自動ステータスとトリガー

GitLabはイベントに応じてMerge Requestのステータスを自動更新します。新しいコミットのプッシュでApprovalsがリセットされ、CIパイプライン成功でPipeline passed、失敗でPipeline failed（マージブロック）になります。Auto-mergeを設定すると、CI成功と全承認取得後にMRが自動マージされます。

• Draft — 下書き、CIは実行するがマージはブロック
• Opened — レビュー準備完了、レビュアー割り当て済み、パイプライン稼働中
• Approved — 必要な承認数を取得
• Merged — 変更がターゲットブランチにマージ済み
• Closed — マージせずに閉鎖

Merge Requestにおけるコードレビューのルール

Merge Request (MR)でのコードレビューは、ほとんどの商用プロジェクトで必須の段階です。SmartBear, 2023の調査によると、MRによるコードレビューは欠陥数を30–60%削減し、新規開発者のオンボーディングを加速します。基本ルールとして、各MRはコード作成に参加していない少なくとも1人、理想的には2人の開発者がチェックする必要があります。

MRレビューには5つの基準があります。論理的正確性、コードスタイル準拠、テストカバレッジ、セキュリティ、パフォーマンスです。GitLabではRequired Approvalsを設定でき、マージ前に必要な承認数を指定できます（例: mainは2承認、developは1承認）。

MRでの議論はスレッドで行われます。特定のコード行へのコメントです。各スレッドはマージ前に解決される必要があります。レビューを迅速化するため、MRサイズは200–400行の変更に制限することを推奨します。Google Research（2022）によると、400行を超えるMRは30%効率的にレビューされません。

Merge RequestにおけるCI/CDパイプライン

Merge Request (MR)を作成すると、CI/CDパイプラインが自動的に開始されます。GitLabでは.gitlab-ci.ymlファイル、GitHubではGitHub Actionsワークフローを通じて行われます。パイプラインにはプロジェクトビルド、単体テスト、リンター、静的解析（SAST）、コードカバレッジチェックが含まれます。

GitLab Blog, 2024によると、パイプラインのステータスはMRに直接表示されます。緑のチェックマーク（passed）、赤いバツ（failed）、黄色い円（running）です。パイプラインが失敗すると、GitLabは修正されるまでMergeボタンをブロックします。設定で“Merge when pipeline succeeds”を有効にすると、パイプライン成功後に自動マージされます。

# .gitlab-ci.yml — Androidプロジェクトの例
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

マージ方法: Squash、Merge Commit、Fast-Forward

GitLabとGitHubはMerge Requestに3つのマージ方法を提供しています。選択はチームポリシーと希望する履歴のきれいさに依存します。Merge Commitは個別のマージコミットを作成し、フィーチャーブランチ全体の履歴を保持します。Squashはブランチの全コミットをターゲットブランチ上の1つのコミットにまとめます。Fast-Forwardはマージコミットなしでコミットを線形に適用します。

GitLab Docs, 2025によると、コミット密度の高いプロジェクト（1つのフィーチャーブランチに20+コミット）ではSquashが推奨されます。Fast-ForwardはTrunk-Based Developmentで必須です。Merge CommitはGit Flowでブランチのセマンティクスを保持するために使用されます。

• Merge Commit — 履歴を保持、マージコミットを作成、Git Flowに適する
• Squash — 全コミットを1つに統合、クリーンな履歴、中間コミットは失われる
• Fast-Forward — マージコミットなしの線形履歴、TBDで必須

ベストプラクティス: 良いMRの書き方

質の高いMerge Request (MR)はレビュー時間とエラー数を削減します。最初のルールは1つのMRが1つのタスクを解決することです。変更が複数の無関係な機能に影響する場合は、個別のMRに分割する必要があります。次に、MRのタイトルは情報提供的であるべきです。「Fix stuff」や「Update code」ではなく「Add OAuth2 authentication with Google provider」のようにします。

Google Engineering Practices, 2024によると、良いMRにはコンテキストの説明が含まれます。なぜ変更が必要か、どのようにテストされたか、どのようなリスクがあるかです。MRのサイズは400行を超えるべきではありません。ボリュームが大きい場合は、タスクをサブタスクに分割する必要があります。ドキュメントとテストについては、説明付きで例外が認められます。

Merge Request (MR)には新しい機能の自動テストを含める必要があります。GitLabではCoverage Checkポリシーを設定でき、コードカバレッジがしきい値（例: 80%）を下回るとMRが自動ブロックされます。これにより、新機能がプロジェクト全体の品質を低下させないことが保証されます。

• 1つのMR — 1つのタスク: 大きな変更は複数の小さなMRに分解する
• テンプレート付き説明: 統一性のため.gitlab/merge_request_templatesを使用
• サイズは400行まで: 大きなMRはレビューが遅くエラーも多い
• テスト必須: 新機能は単体テストでカバーする必要がある

MR説明テンプレート

GitLabは.gitlab/merge_request_templates/ファイルを通じてMerge Requestテンプレートをサポートしています。テンプレートには、何をしたか、テスト方法、関連タスク、チェックリストのセクションが含まれます。テンプレートを使用するとMR作成が迅速化され、開発者が重要な情報を含め忘れることを防げます。MRの説明には、マージ時の自動タスククローズのために関連イシュー（Closes #N）を指定する必要があります。