Git & GitHubの要点

●Git Hubのテキストファイルのpull、またはpushでコンフリクト発生時の対応の手順。

(1)　GUI ツールを使用してソースを修正するケース
1.修正したソースをステージング・コミットして、サーバー側でもソース修正あり、不一致がある場合、pull or pushするとコンフリクトが発生する。
2.git status、git logでコンフリクトを確認する。
3.Gitのコンフリクトマーカーに従って、ソースを修正する。
※GUIツールの利用: SourceTree、VS Code の Git 連携機能などの GUI ツールを使用すると、コンフリクト箇所が視覚的に表示され、より簡単に修正できる場合があります。
git mergetool コマンドを実行すると、設定されたマージツールが起動し、対話的にコンフリクトを解消できます。
事前に git config –global merge.tool <ツール名> でツールを設定しておく必要があります。
4.ステージングする。
5.コミットする。
6.pushする。

Topへ戻る

(2)　現在のブランチのリモートの状態に完全に合わせて修正するケース
1.修正したソースをステージング・コミットして、サーバー側でもソース修正あり、不一致がある場合、pull or pushするとコンフリクトが発生する。
2.git status、git logでコンフリクトを確認する。
3.ローカルで修正したソースのバックアップを取得する。修正したソースファイルをワーキングディレクトリ・ステージングエリア以外にバックアップする、またはファイル名を変更する。
4.現在のブランチのリモートの状態に完全に合わせる
git reset --hard origin/<ブランチ名>
※作業ディレクトリ、ステージングエリア、そしてローカルのコミット履歴（HEADの指す場所）を、指定したコミットの状態に強制的に戻す。
5.取得したソースファイル(リモートと同じ)に、3.でバックアッフしたソースファイルの最新変更内容を追加修正する。
WinMergeなどのツールを使用し、修正箇所を明確にして、ソース修正をする。
6.ステージングする。
7.コミットする。
8.pushする。

Topへ戻る

(3)　特定のファイル（またはディレクトリ）を、リモートの最新の状態に戻して、修正するケース
1.修正したソースをステージング・コミットして、サーバー側でもソース修正あり、不一致がある場合、pull or pushするとコンフリクトが発生する。
2.git status、git logでコンフリクトを確認する。
3.ローカルで修正したソースのバックアップを取得する。修正したソースファイルをワーキングディレクトリ・ステージングエリア以外にバックアップする、またはファイル名を変更する。
4.コンフリクトを起こした特定のファイル（またはディレクトリ）を、指定したコミットの状態に戻す。
git restore --theirs <ファイル名> #(Git 2.23以降推奨)
または
git checkout --theirs <ファイル名>
※(2)の、git reset --hardと異なり、ブランチの履歴や他のファイルの変更には影響しません。
5.取得したソースファイル(リモートと同じ)に、3.でバックアッフしたソースファイルの最新変更内容を追加修正する。
WinMergeなどのツールを使用し、修正箇所を明確にして、ソース修正をする。
6.ステージングする。
7.コミットする。
8.pushする。

Topへ戻る

●Git Hubのバイナリファイルのpullまたはpushでコンフリクト発生時の対応の手順

–git pull or push で Excelファイルなどがコンフリクトした場合に、リモートのファイルを優先してワーキングエリアのファイルは後で追加修正する手順は以下の通りです。
基本的な考え方: コンフリクトした状態では、Git はどちらの変更を保持するかを自動的に決定できません。リモートのファイルを優先するということは、コンフリクトしている Excel ファイルに関して、リモートの最新版をローカルのワーキングエリアに採用し、ローカルでの変更は一旦破棄する形になります。その後、必要に応じてローカルでリモートのファイルに追加修正を加えます。

手順:
1.コンフリクトの確認: まず、git status コマンドを実行して、コンフリクトが発生しているファイルを確認します。
git status
「Unmerged paths」のセクションに、コンフリクトしている Excel ファイルが表示されます。
2.リモートの変更を優先してコンフリクトを解消: 以下のコマンドを実行して、コンフリクトしているファイルに対してリモートブランチのバージョンを採用します。<リモートブランチ名> は通常 origin/main や origin/develop などです。
git restore –theirs <コンフリクトしたExcelファイル名>
または
git checkout –theirs <コンフリクトしたExcelファイル名>
このコマンドは、指定されたファイルの「theirs」（リモート側のバージョン）をワーキングエリアに反映させます。
3.コンフリクト解消済みとしてステージング: リモートのファイルを採用したら、それをコンフリクトが解消されたものとして Git に認識させるために、ファイルをステージングします。
git add <コンフリクトしたExcelファイル名>
4.コンフリクト解消のコミット: コンフリクト解消のコミットを行います。
git commit -m “Resolve conflict: Use remote version of “
コミットメッセージには、どのようにコンフリクトを解消したかを記述しておくと良いでしょう。
5.（必要に応じて）ワーキングエリアのファイルを修正: この時点で、ワーキングエリアにはリモートの最新版の Excel ファイルがあります。ローカルで行っていた変更をこのファイルに追加したい場合は、Excel を開いて手動で修正を行います。
6.修正後のファイルをステージング: 必要に応じて修正を加えたら、そのファイルを再度ステージングします。
git add <修正したExcelファイル名>
7.修正内容をコミット (必要に応じて): 追加修正を行った場合は、その変更をコミットします。
git commit -m “Add local modifications to remote Excel file”
8.プッシュ: 最後に、ローカルの変更をリモートリポジトリにプッシュします。
git push

重要なポイント:
バイナリファイルの場合、Git はコンフリクトマーカーを表示して内容を比較・編集することができません。そのため、どちらのバージョンを採用するか（リモート優先、ローカル優先、または両方の手動マージ）を決定する必要があります。
リモート優先にする場合は –theirs オプションを使用し、ローカル優先にする場合は –ours オプションを使用します。
手動でマージする場合は、それぞれのバージョンのファイルを参照しながら、新しい統合されたファイルを作成する必要があります。
git pull を怠って git push しようとすると、リモートリポジトリとの不整合が発生し、プッシュが拒否されるのが一般的な動作です。その際は、まず git pull でリモートの変更を取り込むことが重要になります。
この手順で、git pull を怠ってコミットしようとした（実際にはプッシュしようとした）際に発生したバイナリファイルのコンフリクトに対応し、リモートのファイルを優先してローカルを更新し、最終的にリモートリポジトリにプッシュすることができます。
ソースファイルの修正登録で説明した、git reset --hardは、
・特定のファイルだけを解決するのではなく、コンフリクトしているマージ自体を破棄し、マージ前の状態に戻してしまいます。
・もしマージ中に他のファイルで手動で解決済みのコンフリクトがあった場合、その解決もすべて失われます。
・未コミットの変更もすべて失われます。
バイナリファイルのコンフリクト解決のためだけに使うには、影響範囲が広すぎ、意図しないデータ損失のリスクが非常に高いため、バイナリファイルのコンフリクト時の対応から外しています。