#概要
前回に引き続きプロジェクトの基本機能について触れていきます。
今回はプロジェクトのマージ実行時の競合について学習していきます。
#競合(コンフリクト)
GitLab上のプロジェクトにあるファイルについて、例えば2人のプロジェクトメンバーがプロジェクトのクローンを行い、全く同じファイルを編集したとします。
メンバーAが編集を完了し、GitLab上のマスターブランチへマージを行います。
当然マスターブランチにはメンバーAが編集したファイルとして更新されている状態になります。
この状態で異なる編集を行ったメンバーBがマスターブランチへマージを実施しようとすると、メンバーBのクローンしたファイルにはメンバーAが編集した内容が反映されていませんので、その差分が発生してしまいます。
この状態を競合(コンフリクト)と呼びます。
実際に競合を発生してみたいと思います。
##競合の発生
まずは以前作成したプロジェクトのクローンを行います。
今回もGitBashを使用します。
GitBash上で上記の通りクローンを行いました。
プロジェクトのディレクトリ内にあるテキストファイルを編集します。
今回は以下画像の青い線が引かれた箇所を追記しました。
その後、以下の要領でコミットからプッシュまで実施しています。
現時点でGitLab上には原本であるmasterブランチと原本を修正したdevelopブランチが存在している状態です。
この状態で一旦別のディレクトリへ移動し、再度クローンを実行します。
現在のブランチはmasterが選択されている状態ですので、再びブランチの切り替えを実施します。
今度はdevelopとは異なる名称で新たにブランチを切ります。
以下の通り新たにdebugというブランチを作成し、切り替えしました。(ブランチ名は適当に付けました…)
新しいブランチにてテキストファイルを以下の通り修正しました。
修正箇所は青線部分です。
先程と同じ要領でGitLabへプッシュまで実施しました。
この時点では特にエラーらしきメッセージは表示されていません。(それぞれ別のブランチで修正しているので当然ですが…)
GitLabへ戻り、まずはdevelopブランチをmasterブランチへマージします。
GitLabのマージリクエストの画面へ移動します。
以下のマージリクエスト画面にある緑の枠で囲った**「New merge request」**をクリックします。
※「マージリクエストを作成」からだと最後にプッシュしたブランチが指定されます。最後にプッシュしたブランチは「debug」ですが、その前にプッシュした「develop」ブランチのマージがまだ未実施なので、「develop」ブランチを指定する必要があります。
「Source branch」欄内の青枠内に選択されているブランチをdevelopに変更します。
「Target branch」はデフォルトでmasterが選択されていますので、ここは切り替え不要です。
この状態で、「Compare branches and continue」をクリックします。
New Merge Requestの画面に移動します。
下記画像の赤線部に「From develop」と記載されている事を確認し、「Submit マージリクエスト」をクリックします。
以下の画面に移動しますので、「マージ」をクリックします。
※前回マージ実行時に、以下の赤線部「ソースブランチを削除」にチェックが入ったままマージしてしまったので、前回のdevelopブランチが消失してしまっていました…
今回はチェックを外しています
特にエラーなく完了しました。
masterブランチのファイルとdevelopブランチのファイルの内容が一致している事がわかります。
この状態で今度はdebugブランチとmasterブランチをマージしてみます。
再びマージリクエストの画面へ移動し、「New merge request」をクリックします。
デフォルトでソースブランチが選択されていない状態となりますので、「ソースブランチを選択」をクリックし、プルダウン内から「debug」を選択します。
Target branchはmasterのまま、「Compare branches and continue」をクリックします。
以下画面の赤線部が「From debug」となっている事を確認し、「Submit マージリクエスト」をクリックします。
すると以下の画面に移動します。
赤枠で囲っている箇所に「マージ」ボタンが表示されていますが、クリックする事が出来ません。
また、赤線部に競合を示すメッセージが表示されています。
これでマージの再現が出来ました。
##競合の解決
競合を発生させたところで、次は競合を解消していきます。
競合を解決させるには、GitLab上で操作する方法と、ローカル上で修正する方法の2パターン存在しているようです。
今回はお手軽なGitLab上での解消方法を試してみます。
まずは以下の画面から「競合を解決する」を選択します。
すると以下の画面に移動します。
ここで表示されている「HEAD //自分の変更」がマージを行えなかったdebugブランチの変更内容で、「origin //相手の変更」はマージ先の変更対象となっています。
以下画面の緑枠の「自分の変更を使用」をクリックするとorigin変更分が削除され、逆に「相手の変更を使用」をクリックするとdebugの変更がキャンセルされる様です。
また、オレンジ枠の「Edit inline」をクリックするとテキストエディタモードになり、編集が出来るようになります。
両方の変更を保持したい場合は、Edit inlineで手動で修正するとよいでしょう。
今回は「Edit inline」を使用し、両方の変更を反映させました。(少し見えづらいですが…)
編集が完了しましたら、「ソースブランチへのコミット」をクリックします。
先程のマージリクエストの画面に戻ります。青線部に競合が解消されたというメッセージが表示されています。
しかしこの状態ではまだ「マージ」ボタンをクリック出来ません。
緑枠内の「承認」をクリックすると、「マージ」がクリック出来るようになります。
※競合の解消内容を他のメンバーにレビューしてもらう事を想定しているのではないかと思います
「マージ」が押せるようになった状態で、「マージ」をクリックしましたところ、以下の画面に切り替わりました。
無事にマージが完了したようです。
マスターブランチ内のファイルを開くと、先程競合の解消を行った際に編集した内容が反映されています。
以上で競合の解消は完了となります。
今回でGitLabのプロジェクトの基本的な使い方は一旦終了となります。
次回はLFSについて学習しようと思います。