マージリクエスト

ソースブランチからの変更をターゲットブランチに取り込むには、マージリクエスト (MR)を使います。

マージリクエストを開くと、マージ前の変更を視覚化したり共同作業したりすることができます。マージリクエストには次のようなものがあります:

  • リクエストの説明
  • コード変更とインラインコードレビュー。
  • CI/CDパイプラインに関する情報。
  • ディスカッションスレッドのためのコメント欄。
  • コミットのリスト。

マージリクエストの作成

マージリクエストを作成するさまざまな方法について説明します。

マージリクエストテンプレートの使用

マージリクエストを作成するとき、GitLabはマージリクエストにデータを追加するための記述テンプレートが存在するかどうかをチェックします。GitLab はこれらの場所を 1 から 5 までの順番でチェックし、最初に見つかったテンプレートをマージリクエストに適用します:

名前プロジェクト UI
設定
グループ
default.md
インスタンス
default.md
プロジェクト
default.md
テンプレートなし
標準コミットメッセージ12345
以下のようなイシュー終了パターンを含むコミットメッセージ。Closes #1234 12345 *
ブランチ名の前にイシューIDを付けたもの。1234-example 1 *2 *3 *4 *5 *
note
印の項目には、イシューの終了パターンも付加されます。

マージリクエストを見る

プロジェクト、グループ、またはあなた自身のマージリクエストを見ることができます。

プロジェクトの場合

プロジェクトのすべてのマージリクエストを表示します:

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. コード > マージリクエストを選択します。

または、キーボードショートカットを使用するには、g +mを押します。

グループ内のすべてのプロジェクトについて

グループ内のすべてのプロジェクトのマージリクエストを表示します:

  1. 左のサイドバーで、Search(検索)を選択するか、Go to(移動)を選択してグループを探します。
  2. コード > マージリクエストを選択します。

グループにサブグループがある場合、このビューにはサブグループプロジェクトからのマージリクエストも表示されます。

担当者

あなたに割り当てられたすべてのマージリクエストを表示します:

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. ドロップダウンリストから、私に割り当てられたマージリクエストを選択します。

または

または

  1. 左サイドバーで、コード > マージリクエスト({merge-request}) を選択します。
  2. ドロップダウン リストから、[割り当て済み] を選択します。

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

  • GitLab 13.0 で導入された approved-by によるフィルタリング。
  • reviewer によるフィルタリングが GitLab 13.7 で導入されました。
  • 承認者候補によるフィルタリングは、13.9でGitLab Premiumに移動しました。
  • approved-by によるフィルタリングは、13.9 で GitLab Premium に移動しました。

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

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. コード > マージリクエストを選択します。
  3. マージリクエストのリストの上で、結果を検索またはフィルタ… を選択します。
  4. ドロップダウンリストから、フィルタリングしたい属性を選択します。いくつかの例を示します:
    • 環境別またはデプロイ日別.
    • ID: フィルター#30 を入力して、マージリクエスト 30 のみを返します。
    • ユーザーフィルター:これらのフィルタのいずれかを入力 (またはドロップダウンリストから選択) して、ユーザーのリストを表示します:
      • Approved-By: ユーザーによって承認されたマージリクエスト。 .
      • 承認者、このユーザーが承認できるマージリクエスト。(詳細については、コードオーナーをお読みください)。
      • レビュアー、このユーザーがレビューしたマージリクエスト。
  5. 属性のフィルタリングに使用する演算子を選択または入力します。以下のオペレーションが使用できます:
    • =:です。
    • !=:ではありません
  6. 属性を絞り込むテキストを入力します。属性によってはNoneや Anyで絞り込むことができます。
  7. 複数の属性でフィルタするには、このプロセスを繰り返します。複数の属性は、論理AND で連結されます。
  8. 降順の場合はを、昇順の場合は 選択します。

環境またはデプロイ日順

GitLab 13.6で導入されました

環境や日付などのデプロイデータによってマージリクエストをフィルタするには、次のように入力(またはドロップダウンリストから選択)します:

  • 環境
  • デプロイ前
  • デプロイ後
note
このメソッドはマージコミットを作成しないため、早送りマージメソッドを使用しているプロジェクトは結果を返しません。

環境でフィルタリングする場合、選択できるすべての環境がドロップダウンリストに表示されます。

Deployed-before もしくはDeployed-afterでフィルタリングする場合:

  • 日付は (マージコミットによってトリガーされた) 環境へのデプロイが正常に完了した日時を指します。
  • デプロイの日付は手動で入力する必要があります。
  • デプロイの日付はYYYY-MM-DD の形式を使用し、日付と時刻の両方を指定する場合は二重引用符 (") で囲む必要があります ("YYYY-MM-DD HH:MM")。

マージリクエストへの変更の追加

マージリクエストに変更を追加する権限がある場合、変更の複雑さや開発環境へのアクセスが必要かどうかに応じて、いくつかの方法で既存のマージリクエストに変更を追加することができます:

マージリクエストへのユーザーの割り当て

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

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. コード > マージリクエストを選択し、マージリクエストを見つけてください。
  3. 右側のサイドバーを展開し、担当者セクションを見つけます。
  4. 編集]を選択します。
  5. 割り当てたいユーザーを検索し、選択します。

マージリクエストはユーザーの割り当て済みマージリクエストリストに追加されます。

複数のユーザーの割り当て

13.9でGitLab Premiumに移行しました。

GitLabは、複数の担当者が責任を持つ場合、マージリクエストの複数の担当者を可能にします:

multiple assignees for merge requests sidebar

マージリクエストに複数の担当者を割り当てるには、テキストエリアで/assign @user クイックアクションを使います:

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. コード > マージリクエストを選択し、マージリクエストを見つけてください。
  3. 右側のサイドバーを展開し、担当者セクションを見つけます。
  4. 編集] を選択し、ドロップダウン リストからマージ リクエストを割り当てるすべてのユーザーを選択します。

担当者を削除するには、同じドロップダウンリストからユーザーをクリアします。

マージリクエストを閉じる

マージリクエストの作業を永久に停止する場合、GitLab はマージリクエストを削除するよりも閉じることを推奨します。マージリクエストの作成者や担当者、プロジェクトの開発者、メンテナー、オーナーのロールを持つユーザーは、プロジェクト内のマージリクエストを閉じることができます:

  1. 閉じたいマージリクエストに移動します。
  2. ページ下部のコメントボックスまでスクロールします。
  3. コメントボックスに続いて、「マージリクエストを閉じる」を選択します。

GitLab はマージリクエストを閉じますが、マージリクエストやそのコメント、関連するパイプラインの記録は保持します。

マージリクエストの削除

GitLab では、マージリクエストを削除するのではなく、クローズすることを推奨しています。

caution
マージリクエストの削除を取り消すことはできません。

マージリクエストを削除するには:

  1. プロジェクトオーナーロールを持つユーザーとして GitLab にサインインしてください。このロールを持つユーザーだけがプロジェクト内のマージリクエストを削除できます。
  2. 削除したいマージリクエストに移動し、編集を選択します。
  3. ページの一番下までスクロールし、マージリクエストを削除を選択します。

マージ元ブランチの削除

マージリクエストのソースブランチを削除することができます:

  • マージリクエストを作成するときに、マージリクエストが受理されたらソースブランチを削除する を選択します。
  • あなたがメンテナーのロールを持っている場合、マージリクエストをマージするときに ソースブランチを削除 を選択します。

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

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

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

  • マージリクエスト 1:feature-alphamainにマージします。
  • マージリクエスト 2:feature-betafeature-alphaにマージ .

これらのマージリクエストが同時にオープンされていて、マージリクエスト 1 (feature-alpha) がmainにマージされた場合、GitLab はマージリクエスト 2 の送信先をfeature-alpha からmainに更新します。

相互にコンテンツが更新されるマージリクエストは、通常これらのいずれかの方法で処理されます:

  • マージリクエスト1はまずmain にマージされます。マージリクエスト2はmainに再ターゲットされます。
  • マージリクエスト2はfeature-alphafeature-alphaマージされます。とfeature-betafeature-alpha内部を含むようになった更新されたマージリクエスト feature-alpha1はmainにマージされます。

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

サイドバーのアクションの移動

Version history
  • GitLab 14.10からmoved_mr_sidebarというフラグで導入されました。デフォルトで有効です。
  • GitLab 16.0では、イシュー、インシデント、エピックに対するアクションも移動するように変更されました。

この機能フラグが有効な場合、右上のマージリクエストアクション({ellipsis_v}) には以下のアクションが含まれます:

GitLab 16.0以降では、同様のアクションメニューがイシュー、インシデント、エピックで利用できます。

この機能フラグが無効の場合、これらのアクションは右サイドバーに表示されます。

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

チームで働くソフトウェア開発者のために:

  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 Pages を使ってステージングにデプロイされます。
  7. 本番チームはそのマージコミットを本番環境にcherry-pickします。

マージリクエストのアクティビティフィルター

フラグ:セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。ユーザーごとに利用できるようにするには、管理者が個人またはグループのユーザーに対してmr_activity_filters という機能フラグを有効にします。GitLab.comでは、この機能はGitLabチームメンバーのみ有効です。

マージリクエストの履歴を理解するには、アクティビティフィードをフィルタリングして、あなたに関連する項目のみを表示するようにしてください。

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. コード > マージリクエストを選択します。
  3. マージリクエストを選択します。
  4. アクティビティにスクロールします。
  5. ページの右側でアクティビティフィルターを選択すると、フィルターオプションが表示されます。以前にフィルターオプションを選択したことがある場合、このフィールドには、「アクティビティ+5」のように、選択の概要が表示されます。
  6. 表示したいアクティビティの種類を選択します。オプションには以下が含まれます:

    • 担当者とレビュアー
    • 承認
    • コメント
    • コミットとブランチ
    • 編集
    • ラベル
    • ロック状態
    • メンション
    • マージリクエストステータス
    • トラッキング
  7. オプション並べ替え({sort-lowest}) を選択すると、並べ替えの順序が逆になります。

選択した順序はすべてのマージリクエストに適用されます。右側の並べ替えボタンをクリックして、並べ替え順序を変更することもできます。

スレッドの解決

コメントの個別解決はGitLab 13.6で削除されました。

マージリクエストでは、会話を終わらせたいときにスレッドを解決することができます。

前提条件:

  • 少なくとも開発者ロールを持っているか、レビュー対象の変更の作成者である必要があります。
  • 解決可能なスレッドはマージリクエストにのみ追加できます。イシュー、コミット、スニペット内のコメントには使えません。

スレッドを解決するには

  1. スレッドに移動します。
  2. 以下のいずれかを行いましょう:
    • 元のコメントの右上隅で、スレッドを解決する({チェックマーク})を選択します。
    • 最後の返信の下にある返信フィールドで、スレッドを解決するを選択します。
    • 最後の返信の下の返信フィールドで、テキストを入力し、スレッドを解決するチェックボックスを選択し、今すぐコメントを追加を選択します。

ページの上部に未解決スレッドの数が更新されます:

Count of unresolved threads

マージリクエストの未解決スレッドをすべてイシューに移動します。

マージリクエストに複数の未解決スレッドがある場合、イシューを作成して別々に解決することができます。マージリクエストのページ上部で、スレッドコントロールの楕円アイコンボタン({ellipsis_v})を選択し、新しいイシューですべてを解決するを選択します:

Open new issue for all unresolved threads

すべてのスレッドが解決済みとしてマークされ、マージリクエストから新しく作成されたイシューへのリンクが追加されます。

マージリクエスト内の未解決スレッドをイシューに移動します。

マージリクエストに特定の未解決スレッドがある場合、それを解決するためのイシューを個別に作成することができます。マージリクエストで、スレッドへの最後の返信の下にある「スレッドを解決する」の横にある「スレッドを解決するイシューを作成する({issue-new})」を選択します:

Create issue for thread

スレッドは解決済みとしてマークされ、マージリクエストから新しく作成されたissueへのリンクが追加されます。

すべてのスレッドが解決されない限りマージしないようにします。

すべてのスレッドが解決されるまでマージリクエストをマージしないようにすることができます。この設定を有効にすると、少なくとも 1 つのスレッドが未解決の場合、マージリクエストの未解決スレッドカウンターがオレンジ色で表示されます。

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定 > マージリクエストを選択します。
  3. マージチェック] セクションで、[すべてのスレッドを解決する必要がある] チェックボックスを選択します。
  4. 変更を保存を選択します。

マージリクエスト内のスレッドが古くなった場合に自動的に解決します。

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

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. 設定 > マージリクエストを選択します。
  3. マージオプションセクションでマージリクエストの差分スレッドが古くなったら自動的に解決するを選択します。
  4. 変更を保存を選択します。

プッシュによって diff セクションが古くなった場合、スレッドが解決されるようになりました。変更のない行のスレッドとトップレベルの解決可能なスレッドは解決されません。

トラブルシューティング

Railsコンソールからのマージリクエストのリベース

/rebase クイックアクションに加えて、Railsコンソールにアクセスできるユーザーは、Railsコンソールからマージリクエストをリベースすることができます。<username>,<namespace/project>,<iid> を適切な値に置き換えてください:

caution
データを直接変更するようなコマンドは、正しく実行したり適切な条件で実行したりしないと、損害を与える可能性があります。念のため、インスタンスのバックアップを復元できる状態にしてテスト環境で実行することを強くお勧めします。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::RebaseService.new(project: m.target_project, current_user: u).execute(m)

誤ったマージリクエストステータスの修正

マージリクエストが変更マージ後もOpenのままになっている場合、Railsコンソールにアクセスできるユーザーはマージリクエストのステータスを修正することができます。<username>,<namespace/project>,<iid> を適切な値に置き換えてください:

caution
データを直接変更するようなコマンドは、正しく実行したり適切な条件で実行したりしないと、損害を与える可能性があります。念のため、インスタンスのバックアップを復元できる状態にしてテスト環境で実行することを強くお勧めします。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::PostMergeService.new(project: p, current_user: u).execute(m)

マージされていない変更のあるマージリクエストに対してこのコマンドを実行すると、マージリクエストに不正なメッセージが表示されます:merged into <branch-name>.

Railsコンソールからマージリクエストを閉じる

マージリクエストを閉じるのにUIやAPIを使ってもうまくいかない場合は、Railsコンソールセッションで閉じるとよいでしょう:

caution
データを変更するコマンドは、正しく実行しなかったり適切な条件下で実行しなかったりすると、ダメージを与える可能性があります。必ず最初にテスト環境でコマンドを実行し、リストアできるようにバックアップインスタンスを用意してください。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::CloseService.new(project: p, current_user: u).execute(m)

Railsコンソールからのマージリクエストの削除

マージリクエストをUIやAPIから削除できない場合は、Railsコンソールセッションから削除することもできます:

caution
データを直接変更するようなコマンドは、正しく実行したり適切な条件で実行したりしないと、損害を与える可能性があります。念のため、インスタンスのバックアップを復元できる状態にしてテスト環境で実行することを強くお勧めします。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
Issuable::DestroyService.new(container: m.project, current_user: u).execute(m)