2022/05/20 GitLabのデモ動画を作りました!このブログの末尾にリンクを張ったのでよろしければご視聴ください。
2022/08/23 一部の図の背景が透過されていて見づらかったので、修正致しました。
皆様こんにちは。SEの小池と申します。
GitLabはリポジトリへのマージの際、コンフリクト (競合) を検知できます。
ただ、どういう風にGUIに表示されるのか・・・気になります。
そんな自分のモヤモヤを解決するために、今回は GitLabで実際にコンフリクト (競合) を発生させると、マージリクエスト画面はどうなるのか を確認します。
なお、この記事は手順ではなく、検証シナリオの説明と結果を述べるだけとなります。
本記事の対象の方
- GitLabでコンフリクト (競合) が発生した際に、マージリクエスト画面がどうなるのか確認したい方。 えらい限定的な…。
今回のブログのゴール
このブログのゴールはこちらです。
- GitLabでコンフリクト (競合) が発生した際に、マージリクエスト画面はどうなるのか把握する。
このブログをお読みいただくにあたっての事前ご連絡事項
- 本記事ではGitにおける "コンフリクト (競合) " がどういう状況を意味しているのかについては説明しておりません。
- 本記事は GitLab Enterprise Edition 14.6.1-ee (Ultimate) における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。
- 本記事の操作説明と画面ショットはGitLabのローカライズを日本語にした状態で説明しております。それ以外の言語をご利用の方は適宜読み替えてください。
- 本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。
シナリオの説明
今回の検証のシナリオを簡単に説明します。
登場人物
まず、登場人物は以下の通りです。
ユーザー 名 | 権限 | シナリオ上の役割 |
---|---|---|
dev01 | developer | 開発者その1。README.mdを変更する。 |
dev02 | developer | 開発者その2。README.mdを変更する。 |
admin01 | owner | プロジェクトのリーダー的な人。今回は以下をやる。
|
マージリクエスト
このシナリオに出てくるマージリクエストです。
マージリクエスト名 | シナリオ上の用途 |
---|---|
feature-dev01-readme.md | 開発者dev01が使うマージリクエスト。 ソースはmainブランチ。 README.mdを編集する。 マージリクエスト feature-dev02-readme.md より先にマージする。 |
feature-dev02-readme.md | 開発者dev02が使うマージリクエスト。 ソースはmainブランチ。 README.mdを編集する。 変更内容の一部が、既にマージ済のマージリクエスト feature-dev01-readme.md と コンフリクト (競合) する。 |
検証シナリオ
この検証のシナリオです。
admin01
がREADME.mdの変更に関するイシューを2個作り、片方にdev01
、もう片方にdev02
をアサインする。admin01
は、先ほど作成した2個のイシューでそれぞれマージリクエストを開始する。dev01
とdev02
は、それぞれ割り当てられたイシューのコメントの通りREADME.mdをローカルで変更し、それぞれのブランチにプッシュする。
admin01
はマージリクエストfeature-dev01-readme.md
で、dev01
によるREADME.mdの変更内容を確認し、承認+マージする。
admin01
はマージリクエストfeature-dev01-readme.md
で、dev02
によるREADME.mdの変更内容にコンフリクト (競合) があることを認識し、競合している変更箇所でどちらの変更を採用するかを決定する。
admin01
はコンフリクト (競合) を解消したマージリクエストfeature-dev01-readme.md
を、承認+マージする。
最終的なmainブランチのREADME.mdを確認する。
コンフリクト (競合) 発生時のマージリクエスト画面
シナリオ[5]の時点で、承認者であるadmin01
はマージリクエストfeature-dev02-readme.md
の画面でコンフリクト (競合) が発生していることを確認できます (地味ですが)。
シナリオ[5]の画面だけだとわかりづらいので、シナリオ[4]のマージリクエスト画面を比較してみましょう。
左がシナリオ[4] (通常時)、右がシナリオ[5] (コンフリクト発生時) のマージリクエスト画面です。
上の画面で [競合を解決する] をクリックすると、下の画面に遷移します。
この画面で、競合する変更内容のどちらを選択するかを決定します。
今回は先にマージをしていた開発者dev01
による変更を採用するとします。
この場合は [相手の変更を使用] をクリックし、[ソースブランチへのコミット] をクリックします。
競合箇所を解決すると、画面上部に 「すべての競合が解決されました。マージリクエストをマージすることができます。」と表示されます。
ここまでがシナリオ[5]の内容でした。ここからはシナリオ[6]の内容です。
GitLab様からお許しをいただけたので、[承認] と [Mark as ready] をクリックしましょう。
これはバージョン依存かもしれないのですが、コンフリクト (競合) を解消した場合はマージリクエストをReady状態にマークすると、[マージ] ボタンではなく [Review changes] ボタンが表示されます。
GitLab様からのお告げに従い、[Review changes] をクリックします。
上の画面で [Review changes] をクリックすると、マージリクエストの [変更] タブに遷移します。
今一度、コンフリクト (競合) 解消後の変更内容を確認し、問題がなければ [概要] タブに戻りましょう。
変更内容を確認したことでGitLab様の気が静まったらしく、今度は [マージ] ボタンが表示されています。
[マージ] をクリックするとソースブランチであるmainブランチへのマージが実行されます。
この時点でシナリオ[6]が完了しました。
以上がコンフリクト (競合) 発生時におけるマージリクエスト画面でございました。
最後に
この度はGitもCI/CDもよくわかっていないど素人SEによるGitLab検証ブログをお読みいただき、誠にありがとうございます。
このブログの目標は以下のとおりでしたが、皆さまはいかがでしたでしょうか。
- GitLabでコンフリクト (競合) が発生した際に、マージリクエスト画面はどうなるのか把握する。
GitLabの製品説明時にコンフリクト (競合) 発生時にどうなるのかというご質問はちょこちょこ頂戴するので、この記事がそういった方々の助けになれば幸いです。
最後までお読みいただき、誠にありがとうございました。
GitLabに関するお問い合わせは、以下のフォームからお願い致します。
GitLab製品 お問い合わせ
GitLab操作デモ動画 (基本編) を作ってみました。(音声の録音は自宅でiPhoneのボイスメモ使うという超低クオリティですが…。)
つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。