マージリクエスト

マージリクエストは、チームがコードをレビューし、ディスカッションを行い、コードの変更を追跡するための一元的な場所を提供します。変更を加えた理由を説明するには、マージリクエストをイシューにリンクし、マージリクエストのマージ時にイシューを自動的にクローズします。

マージリクエストは、特定分野の専門家が提案された変更をレビューし、組織のセキュリティ要件が満たされていることを保証するのに役立ちます。開発プロセスの早い段階でマージリクエストを作成すると、チームはバグやコード品質の問題を把握する時間を確保できます。

マージリクエストを表示すると、以下が表示されます。

• リクエストの説明
• コードの変更とインラインコードレビュー
• CI/CDパイプラインに関する情報
• マージ可能性レポート
• コメント
• コミットのリスト

割り当て担当者とレビュアー

マージリクエストには2つのロールがあります:

• 担当者: マージリクエストのオーナーであり、その進捗に責任を負います。割り当て担当者は通常、作成者です。
• レビュアー: 変更をレビューし、フィードバックを提供します。レビュアーは変更をリクエストできます。また、承認資格がある場合は、マージリクエストを承認できます。

プロジェクトの承認ルールと設定によって、誰がマージリクエストを承認できるかが決まります。

詳細については、担当者を割り当ておよびレビュアーをリクエストを参照してください。

マージリクエストを作成する

マージリクエストを作成するさまざまな方法を学習します。

マージリクエストテンプレートを使用する

マージリクエストを作成すると、GitLabは説明テンプレートの存在を確認して、マージリクエストにデータを追加します。GitLabは、1から5の順にこれらの場所を確認し、最初に見つかったテンプレートをマージリクエストに適用します。

マージリクエストを表示する

プロジェクト、グループ、または自分のマージリクエストを表示できます。

マージリクエストのリストをフィルタリングする

マージリクエストのリストをフィルタリングするには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 左側のサイドバーで、コード > マージリクエストを選択します。
3. マージリクエストのリストの上にある結果を検索またはフィルタリングしますを選択します。
4. ドロップダウンリストから、フィルタリングしたい属性を選択します。例:
   • By environment or deployment date。
   • ID: フィルター#30を入力して、マージリクエスト30のみを返します。
   • ユーザーフィルター:
     • 承認したユーザー: ユーザーがすでに承認したマージリクエスト。PremiumおよびUltimateのみ。
     • 承認者: このユーザーが承認する資格のあるマージリクエスト（詳細については、コードオーナーを参照してください）。PremiumおよびUltimateのみ。
     • マージしたユーザー: このユーザーがマージしたマージリクエスト。
     • レビュアー: このユーザーがレビューしたマージリクエスト。
5. 属性のフィルタリングに使用する演算子を選択または入力します。次の演算子を使用できます。
   • =: 等しい
   • !=: 等しくない
6. 属性をフィルタリングするテキストを入力します。一部の属性は、なしまたは任意でフィルタリングできます。
7. このプロセスを繰り返して、論理ANDで結合された、より多くの属性でフィルタリングします。
8. ソート順（降順の場合は 、昇順の場合は ）を選択します。

環境またはデプロイ日別

デプロイデータ（環境や日付など）でマージリクエストをフィルタリングするには、次のいずれかを入力（またはドロップダウンリストから選択）します。

• 環境
• デプロイ前
• デプロイ後

環境でフィルタリングするには、利用可能な環境のドロップダウンリストからオプションを選択します。

Deployed beforeまたはDeployed afterでフィルタリングするには、デプロイ日付を手動で入力します:

• 日付は、（マージコミットによってトリガーされた）環境へのデプロイが正常に完了した時点を指します。
• YYYY-MM-DD形式を使用します。日付と時刻の両方を指定するには、二重引用符（"YYYY-MM-DD HH:MM"）を使用します。

マージリクエストに変更を加える

マージリクエストに変更を追加する権限がある場合は、いくつかの方法で実行できます。使用するメソッドは、変更の複雑さと、開発環境へのアクセスが必要かどうかによって異なります:

• ブラウザでWeb IDEで変更を編集するには、.キーボードショートカットを使用します。複数のファイルを編集する場合、またはGitコマンドに慣れていない場合は、このブラウザベースの方法を使用します。Web IDEからテストを実行することはできません。
• ファイルの編集とテストの実行の両方を行うためのフル機能の環境が必要な場合は、Onaで変更を編集します。OnaはGitLab Development Kit（GDK）をサポートしています。Onaを使用するには、ユーザーアカウントでOnaを有効にする必要があります。
• Gitおよびコマンドラインに精通している場合は、コマンドラインから変更をプッシュします。

ユーザーをマージリクエストに割り当てる

マージリクエストをユーザーに割り当てるには、マージリクエストのテキストエリアで/assign @userクイックアクションを使用するか、次のようにします:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. 左側のサイドバーで、コード > マージリクエストを選択して、マージリクエストを見つけます。

3. 右側のサイドバーの担当者セクションで、編集を選択します。

4. 割り当てるユーザーを検索し、ユーザーを選択します。GitLab Freeでは、マージリクエストごとに1人のユーザーを割り当てることができます。GitLab PremiumおよびUltimateでは、複数のユーザーを割り当てることができます:

   

GitLabは、ユーザーの割り当てられたマージリクエストページにマージリクエストを追加します。

参加者

参加者とは、マージリクエストを操作したユーザーです。参加者の表示については、参加者を参照してください。

マージリクエストをマージする

マージリクエストのレビュープロセス中に、レビュアーは変更に関するフィードバックを提供します。レビュアーが変更に満足した場合、一部のマージチェックが失敗していても、マージリクエストを自動マージに設定できます。すべてのマージチェックに合格すると、マージリクエストは自動的にマージされ、それ以上の操作は必要ありません。

デフォルトのマージ権限:

• デフォルトブランチ（通常はmain）は保護されています。
• メンテナー以上のロールのみがデフォルトブランチにマージできます。
• デベロッパーは、保護ブランチではないブランチをターゲットとする任意のマージリクエストをマージすることができます。

特定のマージリクエストをマージする権限があるかどうかを判断するために、GitLabは以下を確認します。

• プロジェクトでのあなたのロール。（デベロッパー、メンテナー、オーナーなど）
• ターゲットブランチのブランチ保護ブランチ。

マージリクエストをクローズする

マージリクエストでの作業を完全に停止する場合は、削除するのではなく、クローズしてください。

前提条件:

• 作成者またはマージリクエストの割り当て担当者であるか、プロジェクトのデベロッパー、メンテナー、またはオーナーロールが必要です。

プロジェクトでマージリクエストをクローズするには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 左側のサイドバーで、コード > マージリクエストを選択して、マージリクエストを見つけます。
3. ページの下部にあるコメントボックスまでスクロールします。
4. コメントボックスの後、マージリクエストをクローズを選択します。

GitLabはマージリクエストをクローズしますが、マージリクエスト、そのコメント、および関連するパイプラインのレコードを保持します。

ソースブランチを削除

マージリクエストのソースブランチを削除するには:

• マージリクエストを作成するときに、**マージリクエストが承認されたときにソースブランチを削除します。**を選択します。
• マージリクエストをマージするときに、メンテナーロールを持っている場合は、ソースブランチを削除を選択します。
• マージせずにマージリクエストをクローズするとき、ソースブランチを削除を選択します。

管理者は、プロジェクトの設定でこのオプションをデフォルトにすることができます。

自動マージを設定したユーザー、またはマージリクエストをマージするユーザーがブランチの削除を実行します。そのユーザーが、たとえばフォークしたプロジェクトなどで適切なロールを持っていない場合、ソースブランチの削除は失敗します。

ターゲットブランチのマージ時にマージリクエストを更新する

マージリクエストはしばしば連鎖し、あるマージリクエストが別のマージリクエストで追加または変更されたコードに依存します。小規模で個別のマージリクエストをサポートするため、GitLabは、ターゲットブランチがmainにマージすると、最大4つのオープンなマージリクエストを更新できます。例:

• マージリクエスト1: feature-alphaをmainにマージします。
• マージリクエスト2: feature-betaをfeature-alphaにマージします。

これらのマージリクエストが同時にオープンになっていて、マージリクエスト1（feature-alpha）がmainにマージされる場合、GitLabはマージリクエスト2の宛先をfeature-alphaからmainに更新します。

相互接続されたコンテンツ更新を含むマージリクエストは、通常、次のいずれかの方法で処理されます。

• 最初に、マージリクエスト1がmainにマージされます。次に、マージリクエスト2のターゲットがmainに変更されます。
• マージリクエスト2がfeature-alphaにマージされます。更新されたマージリクエスト1は、feature-alphaとfeature-betaの内容を含むようになり、mainにマージされます。

この機能は、マージリクエストがマージされた場合にのみ機能します。マージ後にソースブランチを削除を選択しても、オープンマージリクエストのターゲットは変更されません。この改善は、フォローアップとして提案されています。

マージリクエストのワークフロー

チームで働くソフトウェアデベロッパー向け:

1. 新しいブランチをチェックアウトし、マージリクエストを通じて変更を送信します。
2. チームからフィードバックを集めます。
3. コード品質レポートでコードを最適化します。
4. GitLab CI/CDで単体テストレポートを使用して変更を検証します。
5. ライセンス承認ポリシーにより、プロジェクトと互換性のないライセンスを持つ依存関係を回避します。
6. マネージャーに承認をリクエストします。
7. マネージャー:
   1. 最終レビューでコミットをプッシュします。
   2. マージリクエストを承認します。
   3. 自動マージ（旧パイプラインが成功したときにマージ）に設定します。
8. GitLab CI/CDの手動ジョブで、変更が本番環境にデプロイされます。
9. あなたの実装は顧客に出荷されます。

会社のウェブサイトのウェブページを作成するウェブデベロッパー向け:

1. 新しいブランチをチェックアウトし、マージリクエストを通じて新しいページを送信します。
2. レビュアーからフィードバックを集めます。
3. レビューアプリで変更をプレビューします。
4. ウェブデザイナーに彼らの変更を実装するよう依頼します。
5. マネージャーに承認をリクエストします。
6. 承認後、GitLabは以下を実行します。
   • コミットをスカッシュします。
   • コミットをマージします。
   • 変更をステージング環境にGitLab Pagesでデプロイします。
7. あなたの本番環境チームは、マージコミットをチェリーピックして本番環境に組み込みます。

マージリクエストのアクティビティをフィルタリングする

マージリクエストの履歴を把握するには、アクティビティフィードをフィルタリングして、自分に関係のある項目のみを表示します。

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. 左側のサイドバーで、コード > マージリクエストを選択します。

3. マージリクエストを選択します。

4. アクティビティまでスクロールします。

5. ページの右側で、アクティビティをフィルタリングを選択して、フィルターオプションを表示します。すでにフィルターオプションを選択している場合、このフィールドにはアクティビティ + 他5件のように、選択内容の概要が表示されます。

6. 表示するアクティビティのタイプを選択します。オプションには以下が含まれます。

   • 担当者とレビュアー
   • 承認
   • ボットからのコメント
   • ユーザーからのコメント
   • コミットとブランチ
   • 編集
   • ラベル
   • ロック状態
   • メンション
   • マージリクエストのステータス
   • トラッキング

7. オプション。ソート（ ）を選択して、ソート順を逆にします。

選択内容は、すべてのマージリクエストで保持されます。また、右側のソートボタンでソート順を変更することもできます。

コメントスレッドの管理

マージリクエストでのディスカッションには、個別のコメントとコメントのスレッドが含まれます。オープン（未解決）なスレッドはマージリクエストのマージをブロックしますが、個別のコメントはブロックしません。スレッドでのディスカッションが終了したら、スレッドを解決します。これにより、表示が折りたたまれます。コメントスレッドが重要であってもマージリクエストをブロックすべきではない場合、ディスカッションを続けるためにイシューに移動します。

すべてのスレッドを展開する

GitLabは、マージリクエストの右上隅にオープンなスレッドの数を表示します。このマージリクエストには3つのオープンなスレッドがあります:

折りたたまれたスレッド内のすべてのコメントを表示するには、スレッドを展開します:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 左側のサイドバーで、コード > マージリクエストを選択して、マージリクエストを見つけます。
3. マージリクエストの右上にあるOpen threadsドロップダウンリストで、スレッドオプション（ ）を選択します。
4. すべてのコメントを表示を選択します。

オープンなスレッドをイシューに移動する

オープンなスレッドを新しいイシューに移動し、マージリクエストのブロックを解除するには:

すべてのスレッドが解決されるまでマージを禁止する

スレッドがオープンなままである間、マージリクエストがマージされるのを防ぐことができます。この設定を有効にすると、少なくとも1つのスレッドがオープンなままである間、マージリクエストのOpen threadsカウンターがオレンジ色で表示されます。

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 左側のサイドバーで、設定 > マージリクエストを選択します。
3. マージチェックセクションで、すべてのスレッドが解決しているチェックボックスをオンにします。
4. 変更を保存を選択します。

スレッドが古くなったときに自動的に解決する

新しいプッシュによってスレッドが記述する行が変更されたときに、マージリクエストがスレッドを自動的に解決するように設定できます。

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 左側のサイドバーで、設定 > マージリクエストを選択します。
3. マージオプションセクションで、期限切れになったときにマージリクエストの差分スレッドを自動的に解決しますを選択します。
4. 変更を保存を選択します。

これで、プッシュによって差分セクションが古くなると、スレッドが解決されるようになります。変更されていない行のスレッドと、最上位の解決可能なスレッドは解決されません。

通知とTo Doを移動する

この機能フラグを有効にすると、通知ボタンとTo Doアイテムボタンがページの右上隅に移動します。

• マージリクエストでは、これらのボタンはタブの右端に表示されます。
• イシュー、インシデント、およびエピックでは、これらのボタンは右サイドバーの上部に表示されます。

関連トピック

• リポジトリを保護する
• マージリクエストをレビューする
• スタックされたマージリクエスト
• マージリクエストを認証する
• テストとレポート
• コメントとスレッド
• コード変更を提案する
• CI/CDパイプライン
• マージリクエストのプッシュオプション
• マージリクエストのタイトル検証