# Git Resolve Conflicts

> Use when merge conflicts occur, when git merge fails with conflicts, or when user needs help resolving git conflicts. Git コンフリクト解消を支援し、コンフリクトを分析して解消案を生成・提示し、ユーザー承認後に適用する。

- Skill: `biwakonbu/git-resolve-conflicts` (Agent Skill)
- Install (CLI): `npx skillmds@latest add biwakonbu/git-resolve-conflicts`
- Raw SKILL.md: https://api.skillmd.com/api/skills/biwakonbu/git-resolve-conflicts/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: biwakonbu (https://skillmd.com/u/biwakonbu)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/biwakonbu/git-resolve-conflicts

---


# Git Resolve Conflicts スキル

## Instructions

このスキルはマージコンフリクトを分析し、解消案を生成・提示して、ユーザー承認後に適用するワークフローを提供します。

**重要**: git コマンドは作業ディレクトリで直接実行する。`git -C` は使用禁止。

### 処理フロー

#### Step 1: コンフリクト状態の検出

以下の git コマンドを**並列**で実行し、コンフリクト状態を把握する:

```bash
git status --porcelain              # UU/AA/DD/AU/UA/DU/UD マーカー検出
git diff --name-only --diff-filter=U  # unmerged ファイル一覧
```

コンフリクト種類の判定:

| 判定ファイル | 種類 | 対応 |
|-------------|------|------|
| `MERGE_HEAD` が存在 | merge コンフリクト | **対応** |
| `REBASE_HEAD` が存在 | rebase コンフリクト | 非対応、エラーメッセージ表示 |
| `CHERRY_PICK_HEAD` が存在 | cherry-pick コンフリクト | 非対応、エラーメッセージ表示 |
| いずれも存在しない | コンフリクト状態ではない | エラー終了 |

rebase/cherry-pick コンフリクトの場合は以下を表示:

```
現在は rebase/cherry-pick コンフリクトの自動解消には対応していません。
手動で解消するか、以下のコマンドで中止してください:
- git rebase --abort
- git cherry-pick --abort
```

#### Step 2: 復元手段の確認

マージコンフリクト中は `git merge --abort` でいつでもマージ前の状態に完全復元できる。
別途バックアップを取る必要はない（`git stash` はコンフリクト状態では実行不可）。

以降の全ステップで、ユーザーが中止を選択した場合のロールバック手段として
`git merge --abort` が利用可能であることを常に案内する。

#### Step 3: コンフリクト分析（履歴ベース）

各コンフリクトファイルについて以下を実行:

##### 3a. ブランチ分岐点の特定

```bash
git merge-base HEAD MERGE_HEAD
```

分岐点を起点に、両ブランチの変更を時系列で把握する。

##### 3b. 両ブランチの変更履歴を取得（並列実行）

```bash
# ours 側（現在のブランチ = main）の変更履歴
git log <merge-base>..HEAD --oneline --follow -- <file>

# theirs 側（マージ元ブランチ）の変更履歴
git log <merge-base>..MERGE_HEAD --oneline --follow -- <file>

# 各コミットの詳細（変更内容の把握に必要な場合）
git show <commit-hash> -- <file>
```

##### 3c. 時系列と変更意図の分析

以下の観点で両側の変更を分析する:

| 分析項目 | 確認内容 |
|---------|---------|
| 時系列 | どちらの変更が先か、どういう順序で変更されたか |
| 変更の種類 | 追加 / 修正 / 削除 / リファクタリング |
| 変更の意図 | コミットメッセージから目的を読み取る |
| 依存関係 | 一方の変更が他方の前提になっていないか |

##### 3d. Read でファイル内容を読み取り

コンフリクトマーカー（`<<<<<<<`, `=======`, `>>>>>>>`）を解析し、
ours 側と theirs 側の具体的なコード差分を把握する。

##### 3e. 解消戦略の決定

履歴分析の結果に基づき、以下のパターンで解消戦略を決定:

| パターン | 典型例 | 解消戦略 |
|---------|--------|---------|
| **追加 vs 追加** | 両ブランチで別の関数/import を追加 | 両方残す（統合） |
| **修正 vs 追加** | 一方が既存コードを修正、他方が新コードを追加 | 両方残す（位置を調整） |
| **修正 vs 修正（同一箇所）** | 同じ関数を別々に修正 | 時系列と意図を加味して統合案を生成 |
| **削除 vs 修正** | 一方がコードを削除、他方が同じコードを修正 | ユーザー判断を求める |
| **リファクタ vs 機能追加** | 一方がリネーム/移動、他方が機能追加 | リファクタを基盤に機能追加を適用 |

**重要**: 元ブランチから切ったブランチのコミットと、
元ブランチの履歴変更・追加による衝突が最も多い。
この場合、両方の変更は独立した意図を持つことが多く、
「両方残す」が正しい解消になるケースが多い。

#### Step 4: 解消案の生成と分類

コンフリクトファイルを2カテゴリに分類:

| カテゴリ | 判定基準 | 確認方式 |
|---------|---------|---------|
| **自明な解消** | 片方が追加のみ / 空白差分のみ / import 文の追加のみ | 一括提示・一括承認 |
| **要判断の解消** | 両方にビジネスロジック変更 / 削除と変更の競合 | 個別提示・個別承認 |

**判定に迷った場合は「要判断」に分類する**（安全側に倒す）。

各コンフリクトについて解消案を生成:
- 両方の変更を統合する案（可能な場合）
- 一方を優先する案
- diff 形式で解消前後を明示

#### Step 5: ユーザー確認（AskUserQuestion）

##### 自明グループ

自明な解消が存在する場合、まとめて提示:

- 解消案の一覧を表示
- AskUserQuestion で確認:
  - header: "自明な解消"
  - question: "以下の自明なコンフリクト解消を一括で適用してよいですか？"
  - options:
    - "はい、一括適用": 全て適用
    - "いいえ、中止": マージ全体を中止

##### 要判断グループ

要判断の解消はファイルごとに以下のフォーマットで提示:

```markdown
## <ファイル名> のコンフリクト解消案

### 変更履歴の概要
- **分岐点**: <merge-base のハッシュ> (<日時>)
- **ours 側 (main)**: N コミット
  - <hash> <message> (<日時>)
  - ...
- **theirs 側 (<branch>)**: N コミット
  - <hash> <message> (<日時>)
  - ...

### コンフリクト箇所
- 箇所 N: 行 XX-YY
  - ours: <変更の説明>
  - theirs: <変更の説明>
  - パターン: 追加 vs 追加

### 解消案
<diff 形式で解消後のコードを表示>

### 判断根拠
<時系列と内容に基づく解消理由の説明>
```

- AskUserQuestion で確認:
  - header: "コンフリクト解消"
  - question: "<ファイル名> のコンフリクト解消案を適用しますか？"
  - options:
    - "はい、適用": この解消案を適用
    - "修正して適用": ユーザーが修正内容を指示
    - "スキップ": このファイルはスキップ
    - "中止": マージ全体を中止

##### 中止の場合

ユーザーが中止を選択した場合:

```bash
git merge --abort
```

元のブランチに戻り、処理を終了する。

#### Step 6: 適用

承認された解消案をファイルに書き込む:

1. **Edit ツール**で各ファイルのコンフリクトマーカーを解消後の内容に置換
2. 解消済みファイルをステージング:

```bash
git add <resolved-files>
```

3. 適用後の確認:

```bash
git status
git diff --staged
```

結果をユーザーに提示し、以下を明示:
- 解消されたファイルの一覧
- スキップされたファイルがある場合はその旨
- ロールバック手順: まだ `git merge --abort` が可能かどうか

#### Step 7: 完了報告

解消結果のサマリーを表示:

- 解消したファイル数 / コンフリクト数
- コミット前であれば `git merge --abort` でロールバック可能

次のステップを案内:

- **merge スキルから呼ばれた場合**: マージコミット作成に戻る
- **直接呼ばれた場合**: `git commit` でマージ完了を促す

### 安全規則

#### 必須

- コンフリクト解消の適用前に**ユーザー承認を必須**とする
- 全ての解消案を提示してからユーザーに判断を委ねる

#### 絶対禁止

- ユーザー承認なしでのコンフリクト解消適用
- `git merge --abort` 以外の破壊的操作
- git config の更新
- `--force` オプション付きの操作

#### 特別警告

以下のファイルにコンフリクトがある場合は特別警告を表示:

- `.env`, `.env.*` - 環境変数ファイル
- `credentials.json`, `secrets.*` - 機密情報ファイル
- `*.key`, `*.pem`, `*.cert` - 証明書・鍵ファイル

警告メッセージ:

```
⚠ 機密ファイルにコンフリクトが検出されました: <ファイル名>
機密情報が含まれる可能性があります。解消案の内容を慎重に確認してください。
```

## Examples

### 正常なコンフリクト解消フロー

```
# Step 1: コンフリクト検出
$ git status --porcelain
UU src/config.ts
UU src/utils.ts

# Step 2: 復元手段の確認
# git merge --abort でいつでもマージ前の状態に完全復元可能

# Step 3: 履歴ベースのコンフリクト分析

$ git merge-base HEAD MERGE_HEAD
abc1234

$ git log abc1234..HEAD --oneline --follow -- src/config.ts
def5678 feat: 新しい認証モジュールの import を追加

$ git log abc1234..MERGE_HEAD --oneline --follow -- src/config.ts
ghi9012 feat: ログモジュールの import を追加

$ git log abc1234..HEAD --oneline --follow -- src/utils.ts
jkl3456 fix: formatDate にタイムゾーン対応を追加

$ git log abc1234..MERGE_HEAD --oneline --follow -- src/utils.ts
mno7890 refactor: formatDate のフォーマット文字列を変更

📋 コンフリクト分析結果:

1. src/config.ts (自明)
   - パターン: 追加 vs 追加（import 文）
   - ours: 認証モジュール import 追加 (def5678)
   - theirs: ログモジュール import 追加 (ghi9012)
   - 解消戦略: 両方残す（独立した追加）

2. src/utils.ts (要判断)
   - パターン: 修正 vs 修正（同一箇所）
   - ours: タイムゾーン対応追加 (jkl3456)
   - theirs: フォーマット文字列変更 (mno7890)
   - 時系列: ours が先、theirs が後
   - 解消戦略: 両方の変更を統合案として生成

# Step 5: ユーザー確認
[自明な解消] src/config.ts の import 統合を一括適用してよいですか？
→ はい、一括適用

## src/utils.ts のコンフリクト解消案

### 変更履歴の概要
- 分岐点: abc1234 (2026-02-10)
- ours 側 (main): 1 コミット
  - jkl3456 fix: formatDate にタイムゾーン対応を追加 (2026-02-12)
- theirs 側 (feature/logging): 1 コミット
  - mno7890 refactor: formatDate のフォーマット文字列を変更 (2026-02-14)

### コンフリクト箇所
- 箇所 1: 行 15-25
  - ours: タイムゾーンパラメータ追加と Intl.DateTimeFormat 使用
  - theirs: フォーマット文字列を ISO 8601 準拠に変更
  - パターン: 修正 vs 修正（同一箇所）

### 解消案
  （diff 形式で統合後のコードを表示）

### 判断根拠
  両コミットは独立した目的（タイムゾーン対応 / フォーマット標準化）。
  theirs のフォーマット変更を基盤に、ours のタイムゾーン対応を適用。

→ はい、適用

# Step 6: 適用
$ git add src/config.ts src/utils.ts
$ git status
$ git diff --staged

# Step 7: 完了報告
コンフリクト解消完了
- 解消ファイル: 2/2
- コミット前であれば git merge --abort でロールバック可能
- 次のステップ: git commit でマージを完了してください
```

### merge スキルからの呼び出し

```
⚠ マージ中にコンフリクトが発生しました。
git-resolve-conflicts スキルでコンフリクト解消を実行します。

[コンフリクト解消フローを実行]

✅ コンフリクト解消完了
マージコミットの作成に進みます。
```

### コンフリクト解消の中止

```
# ユーザーが中止を選択
$ git merge --abort

マージを中止しました。元のブランチに戻ります。
```