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

复杂冲突

多个文件

逐个解决文件中的冲突：

# 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，以尽量减少冲突
• 缩短分支的存续时间
• 就共享文件进行沟通

解决过程中

• 耐心处理
• 了解双方的更改
• 不要盲目地只选“ours”或“theirs”
• 解决后进行测试

解决后

• 运行完整测试套件
• 检查合并结果
• 使用清晰的消息提交

冲突消息

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

检查清单

解决冲突时：

• 已识别所有冲突文件
• 已分析每个冲突（了解双方的更改）
• 已选择解决方式（ours/theirs/合并）
• 已删除冲突标记
• 文件已暂存（git add）
• 测试通过
• 构建成功
• 不再存在冲突标记
• 操作已完成（rebase --continue / commit）

集成

以下情况会调用此技能：

• git rebase 遇到冲突
• git merge 遇到冲突
• PR 显示冲突

此技能可确保：

• 干净地解决冲突
• 不丢失更改
• 合并后代码可正常工作