GitHub Desktop

Gitのコンフリクトとブランチについて理解【Gitバージョン管理システム】-STEP8

Gitのコンフリクトとブランチについて理解【Gitバージョン管理システム】-STEP8

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

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

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

コンフリクトについて

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

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

conflict(コンフリクト)
conflict(コンフリクト)

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

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

conflict(コンフリクト)
conflict(コンフリクト)

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

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

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

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

ローカルリポジトリ削除
ローカルリポジトリ削除

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

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

チェックを入れる
チェックを入れる

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

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

ブランチについて

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

ブランチイメージ
ブランチイメージ

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

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

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

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

ブランチのマージ
ブランチのマージ

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

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

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

コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA