| name | conflict-resolver-zh |
| description | 把 merge/rebase 冲突块用中文讲清"两边各想干啥",引导解决而不自动改文件。当用户说「帮我看冲突 / 解冲突 / 合并冲突在哪 / conflict 怎么改」时触发。 |
conflict-resolver-zh — 冲突中文解读与引导
把 git merge / git rebase 产生的冲突块用中文逐条讲清——ours 想做什么、theirs 想做什么、冲突点在哪、建议怎么合——然后等用户确认,再给出合并后的内容让用户自己应用。不自动改任何文件。
何时触发
- 用户说"帮我看冲突"、"解冲突"、"合并冲突在哪"、"conflict 怎么改"
- 用户说"我 merge/rebase 有冲突"、"
<<<<<<< HEAD 是什么意思"
- 用户粘贴了包含
<<<<<<< / ======= / >>>>>>> 的内容
- 用户说"冲突太多不知道从哪改"
工作流
1. 列出冲突文件与冲突块
在仓库目录执行脚本,列出所有冲突及内容:
bash <skill>/bin/list-conflicts.sh [目录,默认当前]
- 优先用
git diff --name-only --diff-filter=U 找冲突文件(精确)
- 若不在 git 仓库或无
git 命令,退而用 grep 扫 <<<<<<< 标记
- 输出每个文件里各冲突块的行号、ours(当前分支)内容、theirs(传入分支)内容
- 无冲突 → 输出"无冲突"并退出
2. 逐块用中文解读
对每一个冲突块,按以下结构分析并输出:
文件:<路径> 冲突块 #<n>(第 <起始行>–<结束行> 行)
【ours(当前分支)想做什么】
<用白话描述 ours 这段代码/内容的意图>
【theirs(传入分支)想做什么】
<用白话描述 theirs 这段代码/内容的意图>
【冲突点】
<两边修改了什么导致冲突,例如:都修改了同一个函数签名 / 都在同一行插入了不同内容>
【建议】
<三选一:保留 ours / 保留 theirs / 两段融合(给出融合思路)>
<若是语义冲突(都改了同一逻辑),明确提示:此处需人工核对,不能机械取一边>
3. 征得用户确认后给出合并内容
- 对每个冲突块,先问用户:"您倾向于保留哪边,还是需要融合?有什么业务背景可以补充?"
- 用户确认后,给出去掉冲突标记的合并内容(纯文本),由用户自行粘贴/应用。
- 不直接修改文件,不执行
git add,不执行任何写操作。
硬规则
- 不臆断业务意图:拿不准 ours/theirs 在做什么时,直接问用户,不编造解释。
- 语义冲突必须提醒人工核对:两边都修改了同一段逻辑(而不只是格式/空白差异)时,明确标注"语义冲突,建议人工核对",不能机械取一边。
- 代码/冲突内容保留原文:引用冲突块时原样展示,不擅自格式化或翻译代码。
- 不自动解决冲突:无论把握多大,都等用户明确确认后再给出最终内容。
- 不做任何 git 写操作:不执行
git add、git commit、git checkout、文件写入等操作。
- 优先讲清分歧,再给建议:先让用户理解两边各做了什么,再给合并方向,避免用户盲目接受建议。
边界
- 只处理文本格式的 git 冲突标记(
<<<<<<< / ======= / >>>>>>>),二进制冲突无法解读。
- 不替代代码审查;若冲突涉及复杂逻辑,建议用户找相关模块的负责人确认。
- 不联网、不查提交历史(只看当前文件内容)。
- 不保证建议 100% 正确;用户需自行验证合并结果的正确性(跑测试、人工检查)。
