Roo Code 冲突解决技能实战指南基于 Git 历史智能化解 PR 合并冲突【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-CodeRoo Code 的项目级 Skills 目录中内置了roo-conflict-resolution技能它围绕「Git 历史 提交上下文」设计了一套从 PR 解析、冲突暴露、意图分析到智能裁决的完整工作流。本文以 SKILL.md 为骨架结合仓库内的 SkillsManager、SkillTool 与 merge-resolver 规则集 源码完整讲解技能结构、初始化流程、四大工作阶段、启发式裁决规则与可复制的命令组合让你既能读懂技能如何被 Roo Code 加载执行也能直接复用它完成 PR 冲突的自动化化解。技能是什么Roo Code 如何加载与触发它在 Roo Code 中技能Skill以目录形式存在每个技能目录内必须包含一个带 YAML frontmatter 的SKILL.md文件。SkillsManager 负责发现并解析技能元数据它遍历全局与项目下的skills/与skills-{mode}/目录用gray-matter解析 frontmatter并校验name、description等必填字段。以本技能为例其 frontmatter 定义了三个关键字段name: roo-conflict-resolution description: Provides comprehensive guidelines for resolving merge conflicts intelligently using git history and commit context. Use when tasks involve merge conflicts, rebasing, PR conflicts, or git conflict resolution. This skill analyzes commit messages, git blame, and code intent to make intelligent resolution decisions.name必须与技能目录名一致目录为roo-conflict-resolution否则会被 SkillsManager 拒载description是模型判断「何时启用该技能」的依据明确声明了适用场景合并冲突、rebase、PR 冲突、git 冲突解决未声明modeSlugs或mode意味着该技能在所有模式下可用。当模型决定调用技能时会走 SkillTool 的执行链路校验技能名 → 通过resolveSkillContentForMode从 SkillsManager 读取技能内容 → 生成审批消息 → 审批通过后把技能指令注入上下文。技能正文即SKILL.md中 frontmatter 之后的部分会作为 Instructions 整体提供给模型指导其后续每一步操作。此外仓库还提供了更轻量的 Slash 命令入口 roo-resolve-conflicts.md支持/roo-resolve-conflicts #123或/roo-resolve-conflicts 456直接发起冲突解决任务其 frontmatter 中mode: merge-resolver指定了配套的自定义模式。何时使用、何时禁用description与正文中的 When to Use / When NOT to Use 共同界定了技能的触发边界。应当使用的场景包括为某个具体的 PR 解决合并冲突rebase 分支时与目标分支产生冲突需要理解并分析相互冲突的代码改动需要在「保留、合并、丢弃」之间做智能决策需要借助 git 历史辅助冲突裁决。不应使用的场景同样明确当前没有需要解决的合并冲突任务只是不带冲突的常规代码评审工作在没有任何合并场景的全新代码上。这条边界很重要技能的整个流程都以「先通过 rebase 主动暴露冲突」为前提没有冲突时不应空跑流程。初始化四步从 PR 号到冲突清单技能接收一个 PR 号如#123或PR #123随后按 初始化步骤 依次执行四个步骤。Step 1解析 PR 号从输入中提取数字部分校验必须提供有效的 PR 号否则直接终止。Step 2拉取 PR 信息gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName用 GitHub CLI 获取 PR 的标题、描述、源分支headRefName与目标分支baseRefName。这一步的价值在于拿到「为什么改」的上下文——后续所有裁决都建立在对 PR 意图的理解之上。Step 3检出 PR 分支并准备 rebasegh pr checkout [PR_NUMBER] --force git fetch origin main GIT_EDITORtrue git rebase origin/main--force强制检出 PR 分支确保工作区处于干净状态git fetch origin main拉取最新的目标分支GIT_EDITORtrue git rebase origin/main尝试把 PR 分支变基到 main 之上以暴露冲突环境变量GIT_EDITORtrue是关键它把编辑器替换为 no-op 命令确保 rebase 全程非交互不会因等待输入而卡死自动化流程。Step 4检查冲突文件git status --porcelain git diff --name-only --diff-filterU--porcelain输出机器可读状态冲突文件以UU标记--diff-filterU精确列出所有 unmerged 文件形成待解决清单。若此步为空说明 rebase 干净通过按错误处理约定直接告知用户「该 PR 无需解决冲突即可合并」。四大工作阶段从分析到验证初始化之后技能进入 主工作流 的四个阶段。Phase 1冲突分析对每个冲突文件依次执行读取冲突文件定位、、冲突标记提取标记之间的冲突区块对冲突两侧分别运行git blame定位产生改动的提交获取相关提交的 commit message 与 diff分析每个改动背后的意图。Phase 2解析策略在理解意图后为每个冲突制定策略按意图对改动分类bugfix、feature、refactor 等评估改动的新旧程度与相关性判断是结构性重叠还是纯格式差异判断改动能否合并还是必须有一方覆盖另一方把测试更新与相关改动纳入考量。Phase 3冲突解决按策略落地修改对每个冲突应用选定的解决方案在 diff 中对冲突标记做正确转义详见下文「apply_diff 实战」校验解决后的代码语法正确用git add暂存已解决文件。Phase 4验证提交前最终确认git status确认所有冲突已解决检查编译/语法错误复查最终 diff确保解决方案合理汇总每个冲突的裁决理由。Git 命令参考可复制的最小命令集技能内置了完整的命令速查表覆盖从拉取信息到收尾 rebase 的每一步命令用途gh pr checkout [PR_NUMBER] --force强制检出 PR 分支保证干净状态git fetch origin main获取最新 main 分支GIT_EDITORtrue 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_EDITORtrue git rebase --continue解决冲突后继续 rebase非交互工具使用规则见 3_tool_usage.xml还补充了几条实操经验所有 git/gh 操作统一走execute_command而非 MCP 工具命令用链式组合提高效率--format输出结构化结果便于解析。对于非交互场景还有三个通用技巧GIT_SEQUENCE_EDITORtrue跳过交互式 rebase 的 todo 编辑、git commit --no-edit/git merge --no-edit/git cherry-pick --no-edit跳过提交信息编辑。意图优先三条最高优先级最佳实践最佳实践规则集 为冲突裁决定义了四档原则其中三条为 High 优先级。意图驱动裁决High永远优先理解改动背后的意图而非只看代码差异。commit message、PR 描述、issue 引用提供了关键上下文。规则集给出了典型示例当冲突发生在bugfix 与 refactor之间时正确做法是把 bugfix 的逻辑移植进 refactor 后的结构里而不是简单二选一——因为 bugfix 修复的是现有问题refactor 改变的是代码结构二者本应共存。保留所有有价值的改动High只要可能就把两侧非冲突的部分合并进来而不是整侧丢弃。冲突双方往往都包含能共存的有价值改动粗暴舍弃一侧极易引入回归。转义冲突标记High使用apply_diff时必须用反斜杠转义冲突标记否则工具会把它们误判为 diff 语法导致解析失败正确\ HEAD错误 HEAD考虑相关改动Medium跳出冲突本身考察测试、文档、依赖代码中的关联改动。一个看似孤立的改动可能是跨多文件的大功能或大修复的一部分忽略它会破坏整体一致性。启发式裁决规则表当两侧意图都清晰时技能给出四条可套用的裁决启发式类别规则例外Bugfix vs FeatureBugfix 通常优先当 feature 本身已包含该修复时Recent vs Old更新近的改动通常更相关当旧改动是尚未被处理的安全补丁时Test Updates带测试更新的改动通常更完整-Formatting vs Logic逻辑改动优先于格式改动-这些规则服务于同一个目标在意图无法同时满足时优先保住功能正确性与安全性再考虑代码风格。常见陷阱与规避方法技能明确列出四个高频错误及对策盲目二选一可能丢失重要改动或引入回归。对策——总是用git blame与 commit 历史分析两侧。忽略 PR 上下文PR 描述往往解释了改动的「为什么」。对策——解决前必须拉取并阅读 PR 信息。不验证解决结果合并后的代码可能语法错误或引入逻辑 bug。对策——总是检查语法错误并复查最终 diff。diff 中未转义冲突标记、、会被当作 diff 语法。对策——出现在 SEARCH/REPLACE 内容中时一律用反斜杠转义例如\ HEAD。此外3_tool_usage.xml 的错误处理还覆盖了几种边界情况rebase 已在进行中时先git status确认再决定--continue或--abort遇到畸形/嵌套的冲突标记时改用精确搜索块的多次定点编辑二进制文件无法自动合并时依据 PR 意图用git checkout --theirs或--ours选择保留版本代码本身含字面量冲突标记字符串时更要加倍小心转义。apply_diff 实战冲突区块的标准替换写法技能给出了用apply_diff解决冲突的标准模板SEARCH 块内先声明:start_line:锚定起始行再以转义后的冲突标记包围两侧代码REPLACE 块内直接写入合并后的实现。apply_diff pathsrc/feature.ts/path diff SEARCH :start_line:45 ------- \ HEAD function oldImplementation() { return old; } \ function newImplementation() { return new; } \ feature-branch function mergedImplementation() { // Combining both approaches return merged; } REPLACE /diff /apply_diff要点有三一是冲突标记前必须加\\、\、\二是:start_line:45让工具精确定位到冲突起始行减少误匹配三是 REPLACE 区写入的既不是旧实现也不是新实现而是融合两者思路的合并版本——这正是「保留两侧价值改动」原则在 diff 层的落地。工具规则还建议SEARCH 块带足上下文确保唯一匹配、多个相邻冲突尽量合并进同一个 diff。收尾质量检查清单与沟通规范解决前后的检查清单解决前拉取 PR 标题与描述识别所有冲突文件理解整体改动意图。解决中对冲突区段执行git blame阅读 commit message 推断意图判断两侧改动能否合并转义 diff 中的冲突标记。解决后确认无残留冲突标记检查语法/编译错误复查完整 diff记录每个冲突的裁决理由。完成标准所有合并冲突均已解决已解决的文件已完成git add暂存解决后的代码无语法错误每个裁决决定都有文档记录。沟通格式向用户汇报进度时使用结构化格式逐文件说明 HEAD、Incoming 与 ResolutionConflict 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.深入阅读想进一步研究技能机制与本主题可从以下仓库文件入手技能本体.roo/skills/roo-conflict-resolution/SKILL.mdSlash 命令入口.roo/commands/roo-resolve-conflicts.md工作流定义.roo/rules-merge-resolver/1_workflow.xml、2_best_practices.xml、3_tool_usage.xml技能加载与解析src/services/skills/SkillsManager.ts技能内容解析与结果构建src/services/skills/skillInvocation.ts技能工具执行链路src/core/tools/SkillTool.ts掌握了本技能后你可以直接向 Roo Code 输入/roo-resolve-conflicts #123让它自动完成「拉取 PR 信息 → 检出并 rebase → 逐冲突分析 → 意图裁决 → 暂存并汇报」的完整闭环也可以参照SKILL.md的结构与本文的启发式规则为团队定制自己的冲突解决规范。【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考