コンフリクトとブランチについて理解 STEP8

前の記事ではリモートリポジトリに招待した人がpush（プッシュ)できるようにする設定まで解説しました。

リモートリポジトリの製作者以外がプッシュできるようにする設定方法-STEP7パブリックのリモートリポジトリはクローンとプルなどのデータを取得する操作はできますが、プッシュなどのデータに変更を加える操作はできないようになっています。ラボレーターの招待、1つのリモートリポジトリを複数人で編集したい場合は、コラボレーター（共同制作者）の設定を行い共同制作者として招待しなければいけません。...

この章では、複数人が共同作業する際に起こるデータの衝突conflict（コンフリクト)と分担作業をするためのbranch（ブランチ)について解説します。

コンフリクトについて

▪コンフリクト（Conflict）

コンフリクトは、バージョン管理システムであるGitを使用している場合に発生する問題です。コンフリクトは、複数の人が同じファイルの同じ場所を同時に変更し、それらの変更が衝突している状況を指します。つまり、Gitはどの変更を優先するか判断できず、手動で解決する必要があります。

コンフリクトが発生すると、Gitは変更が衝突している場所を示し、ファイルをマージする際に手動で修正を行うよう促します。開発者は、コンフリクトを解決して衝突をなくし、変更を正しく統合しなければいけません。

リモートリポジトリを一人で管理のpush（プッシュ)であれば何も問題は起こりませんが、複数人がリモートリポジトリにpush（プッシュ)の作業をすると変更箇所の競合が発生します。この変更箇所の競合のことをconflict（コンフリクト)といいます。

このconflict（コンフリクト)は同じファイルの同じ行に変更内容が異なった変更内容があった場合に起こり解決する必要があります。

上記の例では、左の人は12行目に【見出し1】と入力していますが、右の人は12行目に【コンフリクト】と入力しています。

この状態でリモートリポジトリにお互いがpush（プッシュ)した場合、リモートリポジトリ側では、どっちを優先させるかわからない状態になります。

上記画像はVSCodeでのconflict（コンフリクト)を指摘されている状態です。

仮にconflict（コンフリクト)が大量に発生してしまい、どう解決していいかわからなくなった場合は、自身のローカルリポジトリを削除してリモートリポジトリをclone（クローン）してデータを整理することをオススメします。

ローカルリポジトリを削除する方法

ローカルリポジトリを削除しても、リモートリポジトリは削除されません。GitHub Desktopを開きCurrent repositoryをクリックし削除するローカルリポジトリの上で右クリックしRemoveを選択。

ローカルリポジトリ削除するにはAlos move this repository to Recycle Binにチェックを入れてRemoveをクリックして削除します。

※チェックを外した場合は、GitHub Desktopのリストから消えるだけでローカルリポジトリは残っています。

clone（クローン)の作り方は下記記事に記載しているのでご確認ください。

リモートリポジトリからローカルリポジトリを作成する方法 clone（クローン）-STEP6複数人で作業する際に、必ず必要になってくることが作業を開始する時は、リモートリポジトリのデータと同じ内容のデータをローカルリポジトリに作る必要があります。このリモートリポジトリからローカルリポジトリを作成する操作をクローン（Clone）といいます。ブラウザのGitHubを開きCode→Code→Open with GitHub Desktopをクリック。...

ブランチについて

▪ブランチ（Branch）

ブランチは、ソフトウェア開発において異なる作業の流れや開発の方向性を管理するためのGitの機能です。ブランチを使用することで、複数の開発者が同時に作業を行い、独立して変更を加えることができます。

通常、プロジェクトの開始時点には「メインブランチ」（通常は「master」または「main」と呼ばれる）があります。このメインブランチは、安定した状態のコードを保持し、本番環境で使用されており、開発者は、メインブランチから新しいブランチを作成して作業を開始します。

新しいブランチは、メインブランチから派生したコピーであり、開発者はそのブランチ上で自由に変更を加えることができます。ブランチ上での変更は、他のブランチには影響を与えません。

ブランチ上での変更が完成したら、開発者は変更内容をメインブランチに統合するためにマージ（Merge）操作を行います。マージにより、ブランチ上の変更がメインブランチに取り込まれます。

ブランチは、複数の開発者が同時に作業するための重要な機能であり、バグ修正や新機能の追加などの作業を効果的に管理するのに役立ちます。また、ブランチを使って実験的な変更を行うこともでき、必要な場合は破棄も可能。

branch（ブランチ)はコミットの履歴を枝分かれさせて作業するための機能です。
masterブランチの1つのブランチのみでプロジェクトを進めていくと、コミットが複雑に混ざって状態を把握しにくくなってしまいます。ブランチを作ることによってmasterブランチに影響されずに、自身のペースで作業を進めることができます。

コミットの履歴から途中でsubブランチを作り枝分かれして作業を進めていくイメージです。masterブランチにコミットしないで、自身のsubブランチにコミットの記録を残していくことができるので、branch（ブランチ)を作ると毎回コンフリクトに悩まされることはなくなります。

※最終的にはmasterブランチにmerge（マージ)しなければいけません。

ブランチのマージについて

ブランチのマージ（Merge）は、異なるブランチで行われた変更を統合するために使用されます。具体的には、別々のブランチで開発が進行し、それらの変更を統合する必要がある場合にマージが行われます。

ブランチを分けて作業をしていて最終的にはmasterブランチにマージさせます。
subブランチの作業が終わってmasterブランチにmerge（マージ)する際にコンフリクトがおきます。

最終的にはmerge（マージ)するから、ブランチを作らなくてもいいのではないかと考えがちですが、branch（ブランチ)を作ることによってmasterブランチでのcommit（コミット)でのconflict（コンフリクト)の解決作業がなくなるので、スムーズに進めることができます。

ここまでが、Gitのコンフリクトとブランチについて理解です。

次の章では、コンフリクトの解決方法について解説します。