mcpField
R
resolve-git-conflicts

resolve-git-conflicts

github.com/tenfyzhong開発044 回インストール2 週間前に更新
リポジトリ

resolve-git-conflicts について

base、ours、theirsを比較し、ステージした変更を検証する、コマンドライン向けのGit競合解決スキルです。マージ、リベース、cherry-pickを自動で続行せず、人による確認のために停止します。

主な機能

  1. 01競合の背景と関連コミットの確認
  2. 02base、ours、theirsの比較
  3. 03最小限の変更による競合解決
  4. 04利用可能なビルドとテストの実行
  5. 05変更をステージしてレビュー待ちで停止

活用シーン

  1. 01マージ中の競合解決
  2. 02リベースやcherry-pickの競合処理
  3. 03検証済みの競合解決内容をレビュー用に準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tenfyzhong/skills-hub --skill resolve-git-conflicts

インストール後、Claude Code で/resolve-git-conflictsを入力して読み込まれたか確認します。

詳細

Git の競合を解決する

概要

CLI で Git の競合を最初から最後まで解決します。base／ours／theirs を分析し、どの変更を残すか、または組み合わせるかを判断して、コードが動作することを確認します。その後、コミットや操作の続行はせず、人によるレビューに移ります。

クイックスタート

  1. git status -sb
  2. git diff --name-only --diff-filter=U
  3. 各ファイルについて base／ours／theirs を確認します：git show :1:PATH、git show :2:PATH、git show :3:PATH
  4. ファイルを編集して競合マーカーのない状態にし、git add PATH を実行します
  5. 利用可能であれば、リポジトリのビルド／テストを実行します
  6. レビューのために作業を止めます。git commit、git merge --continue、git rebase --continue、git cherry-pick --continue は実行しないでください

ワークフロー

  1. 競合が発生した理由を把握します。 git status -sb と git log --oneline --decorate -n 20 を使って、操作の種類と競合するコミットを特定します。
  2. すべてのバージョンを分析します。 git show :1:PATH（base）、:2:（ours）、:3:（theirs）を使います。意図を確認するには git diff --ours PATH と git diff --theirs PATH を使います。
  3. 明確な判断に基づいて競合を解決します。 マーカーを削除し、判断基準に基づいて ours、theirs、または組み合わせた結果を選びます。意図を保つため、変更は最小限に抑えます。ユーザーに編集を依頼せず、変更を直接適用し、判断の根拠を回答に記録します。
  4. コードが動作することを確認します。 定義されていれば、プロジェクトのビルド／テスト／lint コマンドを実行します。定義されていない場合は、利用可能な最小限のスモークテストを実行します。
  5. レビューに引き継ぎます。 変更をステージングして検証した後、作業を止めます。git commit、git merge --continue、git rebase --continue、git cherry-pick --continue は実行しないでください。レビュー用に、判断内容と変更したファイルの概要を簡潔に示します。

判断基準

ours または theirs を自動的に選ばないでください。根拠に基づいて、ファイルごとに判断します。 選択する前に、次の問いに答えてください。

  • どちらのバージョンが現在の API と使用箇所に合っていますか？
  • どちらのバージョンが最新のリファクタリングやコミットの意図に沿っていますか？
  • どちらのバージョンが失敗しているテストでカバーされている、またはその問題を修正しますか？
  • どちらのバージョンが非推奨のコードや参照を削除しますか？
  • 両方を組み合わせると、重複や一貫性のない動作が生じますか？

解釈に関する注意：

  • マージでは、ours は現在のブランチ、theirs はマージされるブランチです。
  • リベースまたはチェリーピックでは、ours は適用先のブランチ、theirs は適用するコミットです。
  • それでも判断がつかない場合は、リスクが最も低い変更を選び、その前提を明記します。

コマンド

目的コマンド
競合しているファイルを一覧表示するgit diff --name-only --diff-filter=U
競合マーカーを確認する`rg -n "<<<<<<<
base／ours／theirs を表示するgit show :1:PATH、git show :2:PATH、git show :3:PATH
ours とファイルの差分を表示するgit diff --ours PATH
theirs とファイルの差分を表示するgit diff --theirs PATH
ours／theirs をすばやく採用するgit checkout --ours PATH、git checkout --theirs PATH
解決結果をステージングするgit add PATH

rg が利用できない場合は、grep -n "<<<<<<<\\|======\\|>>>>>>>" PATH を使います。

例

競合：

function formatUser(user) {
<<<<<<< HEAD
  return `${user.name} <${user.email}>`;
=======
  return `${user.displayName} <${user.email}>`;
>>>>>>> feature/use-display-name
}

解決後（新しいフィールドを使い、フォールバックを維持）：

function formatUser(user) {
  const name = user.displayName ?? user.name;
  return `${name} <${user.email}>`;
}

根拠：機能ブランチでは displayName が導入されましたが、既存の呼び出し元では引き続き name が設定されている可能性があります。

よくある間違い

  • レビューへの引き継ぎ前に、マージ／リベース／チェリーピックを続行する。
  • すべての操作で ours と theirs が常に「自分のブランチ」と「相手のブランチ」を指すと思い込む。
  • ファイルに競合マーカーや未解決のブロックを残す。
  • base と使用箇所の状況を確認せず、片方を自動的に採用する。

コメント

Markdown 対応