conflict-resolution

コンフリクトの解決

概要

コードの整合性を保つため、マージコンフリクトを体系的に解決します。

基本原則： コンフリクトは、単にどちらか一方を選ぶのではなく、慎重に解決する必要があります。

開始時に宣言：「コンフリクト解決を使用して、これらのマージコンフリクトに対処します。」

コンフリクトが発生する状況

次の場合にコンフリクトが発生します。

状況	例
更新された main にリベースする	git rebase origin/main
main をブランチにマージする	git merge origin/main
コミットをチェリーピックする	git cherry-pick [sha]
ローカルの変更がある状態でプルする	git pull

解決プロセス

Conflict Detected
       │
       ▼
┌─────────────────┐
│ 1. UNDERSTAND   │ ← What's conflicting and why?
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 2. ANALYZE      │ ← Review both versions
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 3. RESOLVE      │ ← Make informed decision
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 4. VERIFY       │ ← Tests pass, code works
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 5. CONTINUE     │ ← Complete the operation
└─────────────────┘

ステップ 1：コンフリクトを理解する

コンフリクトが発生しているファイルを確認する

# List files with conflicts
git status

# Output shows:
# Unmerged paths:
#   both modified:   src/services/user.ts
#   both modified:   src/utils/validation.ts

コンフリクトを確認する

# See the conflict markers
cat src/services/user.ts

<<<<<<< HEAD
// Your changes
function createUser(data: UserData): User {
  return { ...data, id: generateId() };
}
=======
// Their changes (main branch)
function createUser(data: UserData): Promise<User> {
  return db.create({ ...data, id: generateId() });
}
>>>>>>> main

履歴を理解する

# See what changed in each branch
git log --oneline --left-right HEAD...main -- src/services/user.ts

# See the actual changes
git diff HEAD...main -- src/services/user.ts

ステップ 2：両方のバージョンを分析する

確認すべき質問

質問	検討事項
自分の変更の意図は何ですか？	自分の機能／修正
相手の変更の意図は何ですか？	相手の機能／修正
互いに両立しませんか？	両方を共存させられますか？
どちらがより新しく、正確ですか？	関連するイシューを確認する
両方を残す必要がありますか？	ロジックを統合する

アプローチを比較する

## Conflict Analysis: src/services/user.ts

### My Change (feature/issue-123)
- Made createUser synchronous
- Reason: Simplified for local testing
- Issue: #123

### Their Change (main)
- Made createUser async with DB
- Reason: Production database integration
- Issue: #456

### Resolution
Keep their async version (production requirement).
My testing simplification should use mocks instead.

ステップ 3：コンフリクトを解決する

解決方法

相手側を採用する（main）

main のバージョンが正しい場合：

# Use their version
git checkout --theirs src/services/user.ts
git add src/services/user.ts

自分側を採用する（自分のブランチ）

自分のバージョンが正しい場合：

# Use your version
git checkout --ours src/services/user.ts
git add src/services/user.ts

手動でマージする（両方）

両方の変更が必要な場合：

// Remove conflict markers
// Combine both changes intelligently

// Result: Keep async from main, add your new validation
async function createUser(data: UserData): Promise<User> {
  // Your addition: validation
  validateUserData(data);

  // Their change: async DB call
  return db.create({ ...data, id: generateId() });
}

# After editing
git add src/services/user.ts

コンフリクトマーカー

すべてのコンフリクトマーカーを削除します。

<<<<<<< HEAD      ← Remove
=======           ← Remove
>>>>>>> main      ← Remove

最終的なファイルにコンフリクトマーカーが残っていないことを確認してください。

ステップ 4：解決結果を検証する

構文チェック

# TypeScript: Check types
pnpm typecheck

# Or for specific file
npx tsc --noEmit src/services/user.ts

テストを実行する

# Run all tests
pnpm test

# Run tests for affected area
pnpm test --grep "user"

視覚的に確認する

# See final resolved state
git diff --cached

# Ensure no conflict markers remain
grep -r "<<<<<<" src/
grep -r "======" src/
grep -r ">>>>>>" src/

ステップ 5：操作を続行する

リベース後

# Continue the rebase
git rebase --continue

# If more conflicts, repeat resolution
# When complete:
git push --force-with-lease

マージ後

# Complete the merge
git commit -m "Merge main into feature/issue-123"

# Push
git push

必要に応じて中止する

解決に問題が発生した場合：

# Abort rebase
git rebase --abort

# Abort merge
git merge --abort

# Start fresh

複雑なコンフリクト

複数のファイル

一度に 1 つのファイルを解決します。

# See all conflicts
git status

# Resolve each
# 1. Edit file
# 2. git add file
# 3. Next file

# When all resolved
git rebase --continue

意味上のコンフリクト

コードは問題なくマージされても、意味的に壊れている場合があります。

// main: Function signature changed
function process(data: NewFormat): Result

// yours: Called with old format
process(oldFormatData);  // No conflict marker, but broken!

解決後は必ずテストを実行してください。

依存関係のコンフリクト

// package.json conflict
<<<<<<< HEAD
  "dependencies": {
    "library": "^2.0.0"
=======
  "dependencies": {
    "library": "^1.5.0"
>>>>>>> main

解決方法：

1. 適切なバージョンを選択する
2. pnpm-lock.yaml を削除する
3. pnpm install を実行する
4. 新しいロックファイルをコミットする

ベストプラクティス

解決前

• コンフリクトを最小限に抑えるため、最新の main を頻繁に取り込む
• ブランチの存続期間を短くする
• 共有ファイルについて連絡を取り合う

解決中

• 時間をかけて取り組む
• 両方の変更を理解する
• やみくもに「自分側」または「相手側」を選ばない
• 解決後にテストする

解決後

• テストスイート全体を実行する
• マージ結果を確認する
• 内容が明確なメッセージを付けてコミットする

コンフリクトメッセージ

PR 中にコンフリクトが発生した場合：

## Merge Conflict Resolution

This PR had conflicts with main that have been resolved.

### Conflicting Files
- `src/services/user.ts`
- `src/utils/validation.ts`

### Resolution Summary

**user.ts:**
Kept async implementation from main, added validation from this PR.

**validation.ts:**
Merged both validation rules (main added email, this PR added phone).

### Verification
- [x] All tests pass
- [x] Build succeeds
- [x] No conflict markers in code
- [x] Functionality verified manually

チェックリスト

コンフリクトを解決する際：

• コンフリクトが発生しているファイルをすべて特定した
• 各コンフリクトを分析した（両方の変更を理解した）
• 解決方法を選択した（自分側／相手側／マージ）
• コンフリクトマーカーを削除した
• ファイルをステージした（git add）
• テストに合格した
• ビルドに成功した
• コンフリクトマーカーが残っていない
• 操作を完了した（rebase --continue ／ commit）

統合

次の場合にこのスキルが呼び出されます。

• git rebase でコンフリクトが発生した場合
• git merge でコンフリクトが発生した場合
• PR にコンフリクトが表示された場合

このスキルにより、次のことを実現します。

• クリーンな解決
• 変更の消失防止
• マージ後も動作するコード