GitLabのマージリクエストを使ったコードレビューの方法
GitLabのマージリクエストは、コードがプロジェクトのメインブランチに入る前にレビューするチャンスです。マージリクエスト（MR）は、
git mergeGitLabのウェブUI内でアクセス可能な操作です。コードをレビューしたら、1回のクリックでマージを開始できます。MR駆動のワークフローを採用することで、すべてのコミットが徹底的にレビューされるという期待を生み出すことで、コードの品質を保証することができます。
マージリクエストは、GitLabエクスペリエンスの基本的な要素の一つです。それは、プロジェクト管理、リポジトリ、CI/CDシステムをコードベースの各変更に対して1つのページに統合します。この記事では、オープンソースのGitLab CEを使用しています。商業版には追加の機能が利用できます。
マージリクエストの作成
GitLab内で新しいマージリクエストを作成するには、サイドバーのリポジトリ > ブランチに移動します。ローカルブランチの変更をGitLabにプッシュしていることを確認してください。マージしたいブランチを見つけ、その名前の右側にある「マージリクエスト」ボタンをクリックします。
マージリクエストのプロパティを定義するためにフォームを使用してください。最初に新しいMRのタイトルを付けます。次に、説明を追加します。説明の基準は、組織やプロジェクトによって異なります。一般的には、自分が行った重要な変更点とその背後にある理由を記録しておくことが望ましいです。
ページの下部に、MRのアサイン先、レビュワー、マイルストーン、ラベルを設定するためのコントロールがあります。これらは、マージリクエストの詳細ページの右側のサイドバーを使用していつでも変更できます。これについては後ほど詳しく説明します。
初期レビューをMRを提出せずに完了することができます。「コミット」と「変更」タブを使用して、正しいコードが含まれていることを確認してください。準備ができたら、緑の「マージリクエストを送信」ボタンを押してMRを開いてください。「マージリクエスト」リンクを使用して、プロジェクト内のすべてのMRを表示できます。
ターミナルからマージリクエストを作成する
GitLabのUIを通じてMRを作成することは、MRにラベル、マイルストーン、説明文を正確にタグ付けすることを促します。しかし、それは時間を大幅に消費する面倒なプロセスです。GitLabは、ブランチをプッシュしつつ同時にMRを作成することを可能にするGitプッシュオプションをサポートしています。
git push -u origin HEAD -o merge_request.create -o merge_request.target=mastergit pushを上記のオプションとともに使用すると、現在のブランチがGitリモートにプッシュされます。リモートブランチがすでに存在しない場合は、ローカルブランチと同じ名前で新たに作成されます。2つの-oオプションはGitLabによって処理されます。それにより、あなたのブランチをmasterにマージするための新しいMRが開かれます。
GitLabは、最新のコミットの情報を使用してMRのタイトルと説明を自動的に入力します。さらに、コミットメッセージでGitLabのイシューを参照することができます。例えば、Fixes #123のように、GitLabが自動的にそのラベルとマイルストーンをMRに適用します。
マージリクエストのレビュー
コードはレビューされるまで完了とは言えません。グループの他のメンバーにあなたのコミットを見てもらうよう簡単にリクエストできます。右のサイドバーを使って、1人以上のレビュアーを選択してください。彼らにはあなたのリクエストが通知されます。
あなたは他のユーザーにあなたのMRを割り当てることもできます。これは、彼らがあなたの変更と互換性を持たせるために責任範囲を更新する必要があることを示すかもしれません。これらの機能の使用方法についての厳密なルールはありません。
MRのレビューを任されたときは、画面上部の「コミット」と「変更」タブに切り替えてください。「コミット」タブでは、あなたのブランチにあるすべての新しいコミットのリストが表示され、「変更」タブでは、コードベースに適用すべきファイルの差分が表示されます。
変更画面のレイアウトは、右上の設定アイコンを使用して調整できます。インライン表示と並列表示のどちらかを選択でき、後者はファイルの「古い」バージョンと「新しい」バージョンを分割表示します。「1回に1つのファイルを表示する」オプションを有効にすることで、集中しやすくなり、画面のパフォーマンスも向上します。
コードの変更を行う
あなたの最善の努力にもかかわらず、時にはMRを確認すると、以前は気づかなかった問題を発見することがあります。ただちにコードエディタに戻る必要はありません。変更画面には、見つけたエラーを修正するための機能があります。
簡単な1行の修正の場合は、該当の行にカーソルを合わせてください。行の左側に表示されるコメントアイコンをクリックします。コメントエディタが表示され、GitLabの標準Markdownエディタが開きます。この機能を利用して、MRの特定の行にコメントすることができます。あなたのメッセージは「概要」タブに表示されます。ただし、私たちは特定の機能として、ツールバーにある「提案を挿入」ボタンを探しています。
ボタンをクリックして、選択した行をコメントに挿入します。コメントエディタを使って、その行を適切な形に編集してください。次に、「レビューを開始」または「今すぐコメントを追加」をクリックします。前者を選ぶと、完了したレビューの後にまとめて提出するために複数のコメントを保持することができます。
コメントを保存すると、疑わしい行の下に「提案された変更」ウィジェットが表示されます。これにより、適用する新しい差分が表示されます。「提案を適用」ボタンをクリックすると、すぐに変更が追加されます。
提案を使用すると、ブラウザを離れる必要がないため、マイナーな問題を修正する時間を大幅に短縮できます。より長い編集が必要な場合は、変更画面の任意のファイルの隣にある三点リーダーアイコンをクリックして、フルGitLab Web IDEで開くことができます。
ドラフト（進行中の作業）マージリクエスト
時には、マージする準備が整う前にコードをプッシュしたくなることもあります。これらのMRを区別するには、タイトルの先頭に「ドラフト」と付けるか、ツールバーのボタンをクリックします。ドラフトMRは、右上の「準備完了としてマーク」をクリックして手動でドラフトステータスを取り消さない限り、マージできません。
この機能は以前「作業中」と呼ばれており、「WIP」というタイトル接頭辞が使われていました。その用語は現在、「ドラフト」に置き換えられ、GitLab 14ではこれが唯一のサポートされるバリアントとなります。両方の形式はGitLab 13で利用可能です。
MRにコミットを追加すると、それらはMRページの概要セクションに表示されます。「前のバージョンと比較する」リンクをクリックすると、これらの変更の差分を独立して確認できます。
バージョンを選択せずに「変更」タブをクリックすると、ターゲットブランチに対するMR全体の差分が表示されます。変更画面の上部にある「[master] と [最新バージョン] を比較」ドロップダウンを使用して、任意の二つのバージョンの差分を表示できます。
レビューを完了する
レビューが完了したら、コードをマージする時です。MRのドラフトステータスが設定されている場合は、それを取り消す必要があります。プロジェクトの設定によっては、作成されたコメントスレッドを「解決」する必要もあるかもしれません。
MRがマージの準備が整ったことを示すには、青い「承認」ボタンを使用します。これは、MRが受け入れられたことをチームに知らせるだけで、GitLab内での何らかのアクションを起こすわけではありません。その後、緑の「マージ」ボタンを押してMRをマージすることができます。
マージ後にブランチが削除されるかどうかを制御するには、「ソースブランチを削除」チェックボックスを使用してください。これにより、ブランチのリストをスリムに保つことができますが、将来的にコンテキストを失う可能性があります。「コミットをスカッシュ」オプションを使うと、MR内のすべてのコミットを1つにまとめることができます。これにより、より整然としたコミット履歴が作成されますが、将来個々の変更を元に戻すことが難しくなります。これらのオプションの利用可能性は、プロジェクトおよびグループ内で定義された設定に依存します。
マージリクエストは、コードを書くことやレビューするための良い構造を提供します。同時に、非常に柔軟で解釈の余地があります。マージリクエストのワークフローをどのように発展させるかはあなた次第です。
この記事では、コードレビュワーに直接関連する機能だけを見てきました。GitLabの他の機能を利用すれば、マージリクエストでさらに多くの情報を見ることができるかもしれません。概要ページには、CIパイプラインのステータス、テストやコード品質のレポート、セキュリティスキャンの出力、ステージング環境のリンクが表示されることがあり、これらはすべて変更がプロジェクトにどのように影響するかを理解する際にMRページを最初の目的地にする要素です。