roo-conflict-resolution

Roo Code 冲突解决技能

何时使用此技能

在任务涉及以下情况时使用此技能：

• 解决特定拉取请求的合并冲突
• 变基与目标分支存在冲突的分支
• 理解并分析代码变更冲突
• 智能判断应保留、合并或舍弃哪些变更
• 使用 git 历史记录辅助制定冲突解决方案

何时不使用此技能

在以下情况下不要使用此技能：

• 没有需要解决的合并冲突
• 任务是常规代码审查，且不存在冲突
• 你正在处理全新的代码，不涉及任何合并场景

工作流概览

此技能通过分析 git 历史记录、提交消息和代码变更，智能地制定冲突解决方案。给定一个 PR 编号（例如“#123”），它会处理整个冲突解决流程。

初始化步骤

步骤 1：解析 PR 编号

从类似“#123”或“PR #123”的输入中提取 PR 编号。验证是否已提供 PR 编号。

步骤 2：获取 PR 信息

gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName

获取 PR 标题和描述，以了解其意图，并确定源分支和目标分支。

步骤 3：检出 PR 分支并准备变基

gh pr checkout [PR_NUMBER] --force
git fetch origin main
GIT_EDITOR=true git rebase origin/main

• 强制检出 PR 分支，确保工作区状态干净
• 获取最新的 main 分支
• 尝试变基到 main，以显示冲突
• 使用 GIT_EDITOR=true 确保以非交互方式变基

步骤 4：检查合并冲突

git status --porcelain
git diff --name-only --diff-filter=U

识别存在合并冲突的文件（标记为“UU”），并创建需要解决的文件列表。

主要工作流阶段

阶段 1：冲突分析

分析每个冲突文件，了解其中的变更：

1. 阅读冲突文件，识别冲突标记
2. 提取 <<<<<<< 和 >>>>>>> 之间的冲突部分
3. 对冲突两侧运行 git blame
4. 获取相关提交的消息和差异
5. 分析每项变更背后的意图

阶段 2：解决策略

为每个冲突确定最佳解决策略：

1. 根据意图对变更分类（修复错误、功能、重构等）
2. 评估变更的新近程度和相关性
3. 检查是存在结构重叠，还是仅有格式差异
4. 确定能否合并变更，或是否应以一项变更覆盖另一项
5. 考虑测试更新及相关变更

阶段 3：冲突解决

应用解决策略来处理冲突：

1. 对每个冲突应用选定的解决方案
2. 确保在差异中正确转义冲突标记
3. 验证解决后的代码语法正确
4. 使用 git add 暂存已解决的文件

阶段 4：验证

验证解决方案并准备提交：

1. 运行 git status，确认所有冲突均已解决
2. 检查是否存在编译或语法错误
3. 审查最终差异，确保解决方案合理
4. 准备冲突解决决策摘要

Git 命令参考

命令	用途
gh pr checkout [PR_NUMBER] --force	强制检出 PR 分支
git fetch origin main	获取最新的 main 分支
GIT_EDITOR=true git rebase origin/main	将当前分支变基到 main（非交互式）
git blame -L [start],[end] [commit] -- [file]	获取指定行的提交信息
git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [sha]	获取提交元数据
git show [sha] -- [file]	获取提交中实际进行的更改
git ls-files -u	列出未合并文件及阶段信息
GIT_EDITOR=true git rebase --continue	解决冲突后继续变基

最佳实践

基于意图的解决（高优先级）

始终优先理解更改背后的意图，而不只是查看代码差异。提交消息、PR 描述和问题引用都能提供关键背景信息。

**示例：**当 bug 修复与重构发生冲突时，应在重构后的结构中应用 bug 修复逻辑，而不是简单地选择其中一方。

保留所有有价值的更改（高优先级）

条件允许时，应合并双方不冲突的更改，而不是完全舍弃一方。冲突双方往往都包含有价值的更改，只要妥善整合，就可以共存。

转义冲突标记（高优先级）

使用 apply_diff 时，始终用反斜杠转义合并冲突标记，以防解析错误：

• 正确：\<<<<<<< HEAD
• 错误：<<<<<<< HEAD

考虑相关更改（中优先级）

不要只关注眼前的冲突，还要了解测试、文档或依赖代码中的相关更改。某项更改看似孤立，实际可能属于更大的功能或修复。

解决启发式规则

类别	规则	例外
Bug 修复与功能	通常优先考虑 Bug 修复	功能包含该修复时除外
新近更改与旧更改	较新的更改通常更相关	旧更改属于安全补丁时除外
测试更新	带有测试更新的更改可能更完整	-
格式与逻辑	优先考虑逻辑更改	-

常见陷阱

盲目选择一方

**问题：**可能会丢失重要更改或引入回归。 **解决方案：**始终使用 git blame 和提交历史分析双方的更改。

忽略 PR 背景

**问题：**PR 描述通常会解释更改背后的原因。 **解决方案：**解决冲突前，始终获取并阅读 PR 信息。

未验证已解决的代码

**问题：**合并后的代码可能存在语法错误或逻辑错误。 **解决方案：**始终检查语法错误并审查最终差异。

差异中的冲突标记未转义

**问题：**未转义的冲突标记（<<<<<<、=======、>>>>>>）会被视为差异语法。 **解决方案：**内容中出现冲突标记时，始终使用反斜杠（\）转义。

应用差异示例

使用 apply_diff 解决冲突时，请采用以下模式：

<<<<<<< SEARCH
:start_line:45
-------
\<<<<<<< HEAD
function oldImplementation() {
  return "old";
}
\=======
function newImplementation() {
  return "new";
}
\>>>>>>> feature-branch
=======
function mergedImplementation() {
  // Combining both approaches
  return "merged";
}
>>>>>>> REPLACE

质量检查清单

解决前

• 获取 PR 标题和描述，了解背景
• 找出所有存在冲突的文件
• 了解正在合并的整体更改

解决期间

• 对冲突部分运行 git blame
• 阅读提交消息，了解更改意图
• 考虑是否可以合并这些更改
• 转义差异中的冲突标记

解决后

• 确认不再存在冲突标记
• 检查语法或编译错误
• 审查完整差异
• 记录解决决定

完成标准

• 所有合并冲突均已解决
• 已暂存解决后的文件
• 解决后的代码不存在语法错误
• 已记录解决决定

沟通指南

报告解决进度时：

• 解释解决决定时，直截了当并使用技术语言
• 重点说明每项冲突解决方案的依据
• 清晰概述合并了哪些内容以及原因

进度更新格式

Conflict in [file]:
- HEAD: [brief description of changes]
- Incoming: [brief description of changes]
- Resolution: [what was decided and why]

完成消息格式

Successfully resolved merge conflicts for PR #[number] "[title]".

Resolution Summary:
- [file1]: [brief description of resolution]
- [file2]: [brief description of resolution]

[Key decision explanation if applicable]

All conflicts have been resolved and files have been staged for commit.