コマンドラインおよび 3 者間エディターで Git マージの競合を解決する方法

Git でマージ競合を解決するには、Git が競合していると報告した各ファイルを開き、<<<<<<<、=======、>>>>>>> マーカーの間にコードを含める必要があるかを決定し、マーカーを削除し、git add でファイルをステージングし、git commit (または git merge --continue) で終了します。取り消すには、git merge --abort を実行してください。このガイドでは、コマンド ラインでそのループを説明し、次にビジュアル 3 方向エディターで説明し、最後に競合を稀にし、簡単に元に戻す習慣を説明します。一時停止したマージ、リベース、またはチェリーピックによって得られる選択肢を練習するには、無料レッスン アクティブな操作を続行、スキップ、または中止する を受講してください。

視覚的な例では、macOS、Windows、および Linux 用に作成した Git クライアントである GitTree を使用します。コンピュータにインストールされている Git が実行されるため、クリックしても入力しても同じ結果が得られます。 GitTree 機能リスト には、より広い概要が記載されています。

Git におけるマージ競合とは実際には何ですか

Git は、各ファイルの 3 つのバージョンを使用して 1 行ずつマージします。base (両方のブランチが共有する最後のコミット)、ours (現在のブランチ、HEAD)、theirs (受信ブランチ、MERGE_HEAD) です。一方の側だけがリージョンを変更した場合、Git はその変更を受け入れます。双方が同じ行を異なる方法で変更した場合、Git は停止し、両方のバージョンをファイルに書き込み、決定をユーザーに任せます。

同じことが git pull、git rebase、git cherry-pick、git revert、および git stash pop でも発生する可能性があります。修正内容は同じです。最後のコマンドのみが異なります。 git status は、競合する各パスにラベルを付けます。

• 両方変更: 両方のブランチが同じ行を変更しました。これはよくあるケースです。
• 私たちによって削除されました / 彼らによって削除されました: 一方がファイルを削除し、もう一方がファイルを変更したため、変更されたファイルを保持するか、削除を確認します。
• 両方追加: 各ブランチは同じパスに異なるファイルを作成しました。

コマンドラインでマージ競合を修正する方法

1. 競合するファイルを見つける

Git はマージが停止した瞬間に競合をリストし、完了するまで git status がリストを保持します。 git diff --name-only --diff-filter=U は、マージされていないパスのみを出力します。

$ git merge feature/login
Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts
Automatic merge failed; fix conflicts and then commit the result.

$ git status
On branch main
You have unmerged paths.

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   src/auth.ts

2. 競合マーカーを読み取る

マーカーの外側のすべてがきれいにマージされました。 <<<<<<< HEAD の後のブロックは現在のブランチ、>>>>>>> feature/login の前のブロックは受信ブランチで、それらは ======= 行で区切られています。

export const retries = 3;
<<<<<<< HEAD
export const timeout = 45;
=======
export const timeout = 60;
>>>>>>> feature/login
export const debug = false;

多くの場合、2 つのバージョンだけでは決定するのに十分ではありません。 Git の zdiff3 競合スタイルを一度設定すると、すべての競合で ||||||| 行の後にベースが表示されます。

$ git config --global merge.conflictStyle zdiff3

<<<<<<< HEAD
export const timeout = 45;
||||||| 556e564
export const timeout = 30;
=======
export const timeout = 60;
>>>>>>> feature/login

これで、メインがタイムアウトを 30 から 45 に引き上げ、機能ブランチが 60 に引き上げられたことがわかります。どのブランチが勝つかではなく、製品に必要な値を決定します。

3. ファイルを編集し、解決済みとしてマークします。

必要なコード (片面、もう片面、ミックスまたは新しいもの) を記述し、すべてのマーカー ラインを削除します。誤ってコミットされた野良 ======= は古典的な壊れたビルドであるため、ステージングする前に Git で残り物をチェックします。

$ git diff --check          # lists any leftover conflict markers
$ git add src/auth.ts
$ git commit                # or: git merge --continue

ファイル全体の一方のバージョンが正しい場合は、それを直接取得してください。 Git がマージ中に競合するすべてのハンクに対して一方の側を優先させるには、代わりに git merge -X ours または git merge -X theirs を使用してマージを開始します。競合しない変更は依然として両方のブランチから行われます。

$ git checkout --ours -- src/auth.ts     # keep the current branch's version
$ git checkout --theirs -- src/auth.ts   # keep the incoming version
$ git add src/auth.ts

4. 操作を終了します

すべてのファイルがステージングされたら、停止したものはすべて続行します: git commit (または git merge --continue)、git rebase --continue、git cherry-pick --continue、または git revert --continue。リベースは、後のコミットで再び停止する可能性があります。ループを繰り返します。

GUI でマージ競合を解決する: 3 方向の Git 競合リゾルバー

マーカーは 2 ラインの衝突には適しています。長いファイル内に多数の競合がある場合、GUI 競合リゾルバーの方が高速で、間違いが起こりにくくなります。優れた Git マージ競合ツールは、3 つのバージョンをすべてまとめて表示し、競合を競合ごとに判断でき、マーカーが残っている間は保存を拒否します。

GitTree では、マージが停止すると、競合の数と競合したファイルのリストを示すバナーが表示されます。 1 つを開くと、エディターがウィンドウ全体を表示します。上部には現在のブランチと受信ブランチが並べて表示され、それぞれにブランチ名のラベルが付けられ、その下に保存されるファイルである 出力 が表示されます。

• 競合ごと: 現在の側、着信側、両方を取るか、どちらも取らないか、それぞれから 1 行を選択します。
• 出力を編集 ボタンでカバーできない部分については手動で行ってください。
• Show Base を使用して共通の祖先を確認します (merge.conflictStyle が diff3 または zdiff3 の場合、Git はそれを書き込みます)。
• 選択を元に戻す。決定を元に戻すことができます。
• 削除されたファイル: 一方がファイルを削除し、もう一方がファイルを変更した場合、その側のファイルを保持するか、削除を確認します。

GitTree では、マーカー ラインがまだ含まれている結果は保存されません。外部マージ ツール: VS Code、Cursor、JetBrains IDE、Beyond Compare、Meld、KDiff3、P4Merge、WinMerge、カスタム プログラム、または Git 独自の merge.tool でファイルを開くこともできます。ファイルを解決せずにツールを閉じると、ファイルは競合したままになります。

マージ前にマージ競合を予測する

Git 2.38 以降、git merge-tree --write-tree は、作業ツリーやインデックスの読み書きやコミットを行わずに、メモリ内でマージを実行します。 --name-only を使用すると、競合する可能性のあるファイルがリストされます。終了ステータスは、競合がある場合は 1 で、マージが正常な場合は 0 です。

$ git fetch
$ git merge-tree --write-tree --name-only HEAD origin/main
0d708adc4a836d088802870278cb1f3daf06355f
src/auth.ts

Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts

GitTree はこのプレビューを実行します。マージ ダイアログには、確認する前に予測された結果が表示されます。各フェッチの後、ブランチをそのアップストリームおよびベース ブランチ (別の設定がない限りメインまたはマスター) と照合し、ブランチ名の横に「2 つのファイルでメインと競合します」などの警告が表示されます。 2 番目のヒントは、変更中のファイルをマークし、フェッチされてマージされていない他のブランチも変更されることを示します。

どちらのチェックでも、すでにフェッチしたもののみが使用されます。計算のためにフェッチ、マージ、または変更されるものは何もなく、コンピューターから何も残されません。どちらも環境設定でオフにできます。

git rerere を使用して競合解決を再利用する

レレレとは「Reuse Recorded Resolution」の略称です。これを有効にすると、Git は各競合とその解決方法を記録します。長期間存続するブランチのリベースを繰り返したり、マージをやり直したりした場合など、同じ競合が再発した場合、Git は以前の解決策をファイルに書き込みます。

$ git config --global rerere.enabled true
$ git rerere forget src/auth.ts   # drop a recorded resolution that was wrong

rerere.autoUpdate が設定されていない限り、Git は再利用された結果をレビューのためにステージングせずに残します。 GitTree のリポジトリ設定には、これらの Git オプションの 記録された解像度の再利用 (rerere) および 再利用された解像度のステージング スイッチがあります。競合ビューでは再利用された解決策にラベルが付けられ、解決策を忘れる により間違った解決策が削除されます。

Git でマージを中止またはキャンセルする方法

競合により停止したマージをキャンセルするには、git merge --abort を実行します。リベース、チェリーピック、またはリバートには独自の中止があります。

$ git merge --abort
$ git rebase --abort
$ git cherry-pick --abort
$ git revert --abort

Git 自体のドキュメントでは、マージ開始時にコミットされていない変更を git merge --abort が常に再構築できるわけではないと警告しています。マージする前にコミットまたはスタッシュし、中止では復元するコミットされた作業のみが行われます。

GitTree では、Abort Merge (または Abort Rebase、Cherry-Pick、Revert) で、Git が操作前のブランチ、インデックス、作業コピーを復元し、それまでに行われた解決策が破棄されることを最初に説明します。 GitTree は、ステージングされているかどうかにかかわらず、中断によってドロップされたすべてのものを回復スナップショットに保存するため、「元に戻す」で元に戻すことができます。

マージをコミットした後に元に戻す方法

何をすべきかは、マージをプッシュしたかどうかによって異なります。

# Not pushed yet, right after the merge:
$ git reset --hard ORIG_HEAD     # also discards uncommitted changes
$ git reset --merge ORIG_HEAD    # keeps uncommitted changes

# Already pushed:
$ git revert -m 1 <merge-commit> # a new commit that reverses it

マージではブランチの以前のヒントが ORIG_HEAD に保存されるため、後でリセットまたはリベースで ORIG_HEAD が移動されない限り、それにリセットするとマージが削除されます。他の人がマージを行ったら、代わりに元に戻します。マージを元に戻すと、それらの変更は不要であることが Git に伝えられます。そのブランチを再度マージしても、元に戻さない限り変更は元に戻りません。

GitTree では、グラフ内のマージの最初の親 (ブランチが以前に存在していたコミット) を選択し、コミット メニューからその親に対するソフト、混合、またはハード リセットを選択します。それぞれに保持される内容のラベルが付いています。 GitTree は実行前に 19 種類の操作のスナップショットを作成します。これにはリセットも含まれます。そのため、[元に戻す] でリセットを元に戻すことができ、reflog ビューは古い状態を復元します。 リセット、リベース、またはコミットを元に戻すガイド では、リカバリについて詳しく説明しています。

ほとんどのマージ競合を防ぐ方法

• 分岐は小さく、存続期間を短くしてください。 2 つの分岐が長くなるほど、両方が接触する線が多くなります。
• ベース ブランチを最後に一度だけではなく、頻繁に取り込みます。
• フォーマットをロジックから分離します。 1 つのフォーマッタに同意し、ファイル全体の再フォーマットを独自に実行します。
• 手動でロックファイルをマージするのではなく、ロックファイルを再生成します。 どちらかの側を選択して、パッケージ マネージャーを再度実行します。
• zdiff3 をオンにして、一度再実行します。 2 つのコマンドで永続的なメリットが得られます。
• 統合する前にコミットまたはスタッシュすると、すべての中止と取り消しが正確になります。

まずは安全なリポジトリで練習してみませんか? Git チュートリアル の無料レッスン 分岐したブランチをマージし、両方の親を確認する では、実際のマージについて説明します。まだ端末と GUI を比較検討していますか? Git GUI vs コマンド ライン では、両方を正直に比較しています。

GitTree には、プライベート リポジトリを含むすべての Git 機能をカバーする無料プランがあり、AI アシスタントの Nour には GitTree Pro が付属しています (価格 を参照)。サインインするには、Git 2.39 以降と GitTree アカウントが必要です。macOS、Windows、または Linux 用に入手するか、GitTree ダウンロード ページ ですべてのインストーラーを参照してください。 Ubuntu 22.04 で、最初に Git をアップグレード。頑固な対立から抜け出せなくなっていませんか？ GitTree サポートに問い合わせてください。