GitHub Desktopでマージ競合を安全に解消する
この記事の結論
競合した両側の変更意図、最終テキスト、バイナリの選択を確認します。Accept Bothの重複と最終差分を検証してマージを完了し、中止する場合も元の作業を保全します。
一般的な切り分けガイドです。特定の不具合が現在発生しているという告知ではありません。
対象製品・影響範囲
- 製品
- GitHub Desktop
- 対象バージョン・条件
- GitHub Desktop for Windows and macOS
発生する症状
- Merge conflictsの一覧が表示される
- Continue mergeが押せない
原因・発生条件
競合ファイルをエディターで解決し、マーカーを除去してからDesktopでマージを継続します。
作業前の準備
- 作業前に現在ブランチ、マージ元、未コミット差分、競合ファイル一覧を記録・保全します。
- 変更は一項目ずつ行い、各段階で元の症状を再現して結果をメモします。
この操作の注意点
- 確認対象と無関係な設定やデータをまとめて削除しません。
- 診断記録には個人情報や認証情報を含めず、現在ブランチ、マージ元、未コミット差分、競合ファイル一覧のうち必要な範囲だけ共有します。
使用するツール・公式ページ
この手順の設定名、制限事項、更新された分岐を公式ページで確認できます。
競合ファイルを編集できる既存のエディターがあれば、新しくインストールする必要はありません。
具体的な操作手順
Current branchとマージ元、競合ファイル一覧を確認し、未コミット作業が混在していないか見ます。
不明なら先にリポジトリ全体を複製して退避します。
Desktop上部のCurrent branchは取り込み先です。向きを逆にすると別ブランチへマージするため、開始前に履歴グラフとブランチ名を読みます。
GitHub Desktop上部の［Current branch］で取り込み先を確認し、［Branch］→［Merge into current branch］を開いた場合は取り込む側の名前をもう一度読みます。
開始前にCurrent Branchと取り込むブランチを控えます。向きが逆でも競合解消の画面は出るため、意図したブランチへ入れる操作かを確認します。未コミット編集を保全し、取り込み前から存在した作業と競合解消中に書いた内容を区別すると、中止が必要な場合の復旧を判断しやすくなります。
この手順で使う公式リンク
- GitHub Desktop公式：ブランチの同期とマージ
この手順の設定名、制限事項、更新された分岐を公式ページで確認できます。
次へ進む前の確認取り込み先と取り込み元のブランチ名を確認し、無関係な編集を退避してから競合を解消します。
- GitHub Desktop公式：ブランチの同期とマージ
［Open in Visual Studio Code］等で各ファイルを開き、Current、Incoming、両方、手編集から意図する内容を選びます。
<<<<<<<、=======、>>>>>>>はGitの境界なので最終内容から全て除きます。
VS CodeのAccept Bothは単純連結です。同じ関数や設定キーが両側にあれば重複するため、マーカー除去後に意味の通る一つの実装へ編集します。
CurrentとIncomingは今のマージ操作に基づく呼び方です。日時が新しいからIncomingを選ぶのではなく、機能追加とバグ修正の双方が必要かを確認します。周囲のコードまで読み、片方の処理を残すことで参照先が消えないか、設定値が二重にならないかを確認します。
この手順で使う公式リンク
- Visual Studio Code 公式ダウンロード
競合ファイルを編集できる既存のエディターがあれば、新しくインストールする必要はありません。
次へ進む前の確認各ファイルを保存し、競合マーカーと意図しない関数・設定キーの重複が残っていないことを確認します。
- Visual Studio Code 公式ダウンロード
ファイルを保存し、テストや構文検査を実行します。生成物だけを直さず対応するソースも確認します。
バイナリ競合はテキスト結合せず正しい片方を選びます。
Desktopの競合一覧でチェックが消えても、構文が正しい保証ではありません。プロジェクト固有のテスト、lint、ビルドを実行します。
マージ完了後はHistoryと最終差分を確認します。Push前に必要な検証を行い、競合ファイル以外の関連設定も確認します。検証に失敗したら競合マーカーを消したことだけを完了条件にせず、結果の差分から問題箇所を修正し、最終内容が変更目的を満たすか確認します。
次へ進む前の確認プロジェクトのテストとビルドが通ることを確認し、構文エラーがある場合はマージを完了せず修正します。
Desktopへ戻り全競合がresolvedになったことを確認し、［Continue merge］でマージコミットを作ります。
履歴と差分を読み、意図しない大量削除がないことを確認してからPushします。
Continue merge後は通常のコミット同様にローカル履歴へ入ります。Push前ならHistoryと差分を再確認でき、誤りを外部へ公開せず修正できます。
次へ進む前の確認Historyでマージコミットと意図した差分を確認してからPushします。
競合ファイルでは現在のブランチ側と取り込む側の変更目的を先に確認します。設定値の変更と機能追加が重なった例では、片方のブロックを丸ごと採用するだけで片方の目的が失われる場合があります。
Accept Bothは重複行、二重定義、相反する設定も残します。マーカーを消した後は周囲の関数、JSONのカンマ、importの重複まで確認し、競合が消えた表示と動く実装を区別します。
画像やバイナリはテキストのように行単位で混ぜられません。どの版を残すかを作成者と確認し、必要なら両方を別名で保全してから、採用したファイルを対象アプリで開きます。
解決後の差分で、意図しない削除や無関係なファイル変更がないかを確認し、対象機能のビルドや必要な検証を行います。新しいコミットだけでなく、マージによって残った最終内容を確認します。
マージの取り消しが必要なら、現在の未コミット編集を保全してからDesktopが提示するAbort操作を使います。reset --hardや強制pushを競合解消の代わりに実行すると、別の作業を失う恐れがあります。
改善したか確認する
- テスト成功後にHistoryでマージコミットの親とFiles changedを確認する
- 問題の操作以外の基本機能も確認し、修正による副作用がないことを確かめます。
改善しない場合・設定を戻す場合
- 解釈できない競合はAbort mergeし、変更を退避してレビュー担当者と再実行する
- 回避策で作業を続ける場合も、原本やアカウントデータを別の場所へ保全します。
このガイドの適用範囲
対処ガイド — 競合した両側の変更意図、最終テキスト、バイナリの選択を確認します。Accept Bothの重複と最終差分を検証してマージを完了し、中止する場合も元の作業を保全します。
掲載内容は2026-10-13の情報確認に基づきます。以降の変更は公式出典でご確認ください。
よくある質問
Abortできますか？
未解決中はDesktopのAbort mergeで開始前へ戻せますが、その後の編集は退避してください。
両方を選べば安全ですか？
重複や矛盾が残るため、選択後に手動で最終形を検証します。
競合マーカーを消せば解決ですか？
Gitが競合を認識しなくなることと、コードや設定が正しいことは別です。構文、重複、参照先、両側の変更意図を確認し、対象機能を検証します。Accept Bothで同じ処理が二重になっていないかも見ます。
画像にもAccept Bothを使えますか？
バイナリはテキストのような行単位結合ができません。作成者と残す版を確認し、必要なら両方を別名で保全します。選択した画像や設計ファイルを実アプリで開き、意図した内容になっているか確認します。
出典・情報の更新
- 主な出典の更新・解決日
- 公式ページで日付を特定できないため記載していません
- 本サイトの確認日
- 2026-10-13
公式情報を日本語で整理しています。メニュー名は製品の表示言語や版によって異なる場合があります。確認日は障害の発生日を意味しません。編集方針