基于 Git 冲突的意图式解决法深入解析 resolving-merge-conflicts 技能【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills导读resolving-merge-conflicts是当前仓库skills13/skills中一个面向工程实践的核心技能专门用于处理正在进行的 git merge / rebase 冲突。它不把冲突当作文本拼接问题而是强调先追溯每一方变更的主来源primary source——提交信息、PR、原始 issue——再逐 hunk 解决冲突并在提交前跑完项目自身的自动化检查。读完本文你将掌握一套可复制的「五步冲突解决工作流」、为什么不能依赖--ours/--theirs按旗标盲解、以及为什么--abort在技能中被明令禁止。本文以 resolving-merge-conflicts/SKILL.md 及其配套文档 docs/engineering/resolving-merge-conflicts.md 为主体并结合仓库源码与相邻技能进行纵深印证。技能是什么定义与触发方式该技能在仓库中的正式定义位于 SKILL.md 的 frontmatter--- name: resolving-merge-conflicts description: Use when you need to resolve an in-progress git merge/rebase conflict. ---配套的 Agent 元信息位于 agents/openai.yamlinterface: display_name: Resolving Merge Conflicts short_description: Resolve merge and rebase conflicts在 skills/engineering/README.md 中它被归类为Model-invoked模型可自动调用的技能——这意味着只要任务匹配git 已在冲突处停下Agent 可以主动拾取它而不必等用户手动输入。触发方式有两种用户直接输入/resolving-merge-conflicts或当任务恰好匹配时Agent 自动调用该技能。它的适用边界非常明确git 已经停下、且自身无法解决的冲突。技能只针对眼前这一个冲突不越界处理冲突两侧的其它事务。你的处境应该用哪个技能正在 merge 或 rebase 中途工作区出现冲突标记本技能resolving-merge-conflictsMerge 已完成但合并后的代码行为异常、原因不明转向 diagnosing-bugs正在规划如何切分工作、让分支尽量少碰撞两者都不用见下文「平行工作」讨论五步核心工作流SKILL.md 给出了五个步骤这是整个技能的灵魂逐条拆解如下第 1 步看清当前状态先查看 merge/rebase 的当前状态检查 git 历史与发生冲突的文件。这一步建立事实基础——哪些文件冲突、冲突发生在哪个提交链上、当前处于 merge 还是 rebase 的中途。第 2 步为每个冲突找到主来源这是全技能的关键一步。对每一处冲突都要深入理解每一方变更为什么存在、原始意图是什么阅读提交信息commit message查看 PR 内容查阅原始 issue / ticket。只有在历史中完成这一轮追溯后才进入 diff。技能配套文档 docs/engineering/resolving-merge-conflicts.md 中有一句核心论断「你无法保留一个你尚未读过的意图。」You cannot preserve an intent you have not read.因此工作从历史开始而不是从差异开始。第 3 步逐 hunk 解决冲突解决每个冲突块时遵循三条铁律双方意图尽量都保留当两边的行为可以兼容时把两边的行为都合进来真正不可兼容时选择与本次 merge 既定目标一致的一侧并显式记录代价trade-off即明确注明丢弃了什么、为什么丢弃绝不发明新行为不为了掩盖冲突而凭空新增任何两边都不存在的代码。配套文档强调这一步拒绝「按旗标盲解」的失败模式——用--ours、--theirs或手工删掉看起来不重要的一块让冲突标记消失、让构建能编译通过。这种解决方式可能在语法上完美却会悄悄丢掉某个人有意做的变更。第 4 步发现并运行项目自身的自动化检查找到项目的自动化检查automated checks并运行典型顺序是先类型检查typecheck再测试tests最后格式化format。修复任何由合并引入的问题。配套文档点明了这一步的深层原因merge 是 git 中最容易产生「同时满足两个分支、却通不过任何一方测试」的代码的地方。因此检查必须在提交之前运行并通过而不是等你事后发现坏了才补跑。第 5 步完成 merge / rebaseStage 全部内容并提交commit如果正在 rebase则继续 rebase 过程直到所有提交都重放完毕——多提交 rebase 中剩余每个提交都要处理干净不能半途而废。为什么永远不用--abortSKILL.md 第 3 步明确写道Always resolve; never--abort。配套文档给出了完整论证Aborting throws away the resolution work and returns you to the same conflict, unchanged, the next time you try.即--abort会丢弃已经完成的全部解决工作下次尝试时你面对的还是同一个冲突一无所获。该技能是为「merge 必然要发生」的场景设计的如果你已经决定这次合并不应该发生那应该在调用本技能之前做这个决定而不是把它作为循环内的一个分支。这与本仓库中另一个技能 git-guardrails-claude-code 的安全理念形成互补后者通过 Claude Code 的 PreToolUse hook 拦截git push、git reset --hard、git clean -f、git branch -D等破坏性命令见 block-dangerous-git.sh从工具层防止 Agent 走危险捷径而resolving-merge-conflicts从方法论层禁止--abort这个逃避路径。两者都服务于同一个目标让 git 操作总是收敛到可提交、可验证的状态。主来源优先于ours/theirs配套文档用一个专节阐述了「主来源primary source」方法论「按旗标解决」是这项技能要消灭的失败模式。--ours / --theirs / 手工删掉看起来不重要的一块 → 冲突标记消失、构建编译通过 → 但某个人有意做的变更被静默丢弃解决之道在于解决者必须在动任何一个 hunk 之前把每一侧追溯回它的主来源——提交信息、PR、原始 issue——从而在两个意图之间做选择而不是在两段文本之间做选择。两者兼容就都保留不兼容就选与 merge 目标一致的一侧并命名代价绝不发明新行为来糊弄过去。配套文档还点出了第二步存在的另一个理由技能会找到仓库自己的自动化检查并在提交前运行。因为 merge 最容易产生「两边都满足、两边测试都过不了」的代码主来源追溯负责「不丢变更」自动化检查负责「不引入坏代码」。验证是否成功验收清单配套文档的「Its working if」给出了一组可操作的验收标准可以当作解决完成后的自检清单Agent 在解决冲突时会引用提交信息、PR 或 issue而不是只引用 diff hunk每个 hunk 最终要么保留双方行为要么带有一条显式说明标注丢弃了什么、为什么最终结果中没有出现两个分支上都不存在的新内容typecheck、tests、format 是在提交前定位并跑绿而不是等你发现坏了之后才补跑最终停在一个干净的工作区整个操作包括多提交 rebase 的剩余每个提交全部完成。常见问题与设计取舍「Claude Code 自己解决冲突已经不错了为什么还需要技能」附加价值在于「找主来源」和「跑反馈循环」这两步——否则它们每次都要靠人工提示。未经提示的 Agent 通常会只看 diff 就给出一个「看起来合理」的解决并停在那里。该技能的价值正是它不允许 Agent 跳过的两个步骤读懂每一侧为什么存在以及事后跑检查。配套文档坦率地承认这在优秀模型之上只是「薄薄的一层余量」甚至有读者预言随着模型变强这个技能最终可能变成空操作no-op——这是有意为之的边界克制。「要不要把平行 Agent 隔离到不同文件从源头避免冲突」大多数情况下不需要。把文件分区隔离给平行任务的成本大于收益因为 Agent 已经足够擅长解决冲突这个权衡并不像看上去那么苛刻。唯一值得保留的纪律是先做大规模重构。一个大型重命名落地后再有十个分支从它上面分叉这种情况才是真正昂贵的冲突来源。配套文档还记录了一个来自平行 worktree 用户报告的告诫当多个并行会话各自在自己的 tree 里完成一个 ticket 时合并回去最好由写下该变更的那个会话来做——因为只有它已经知道意图。把所有人的冲突最后堆给一个 Agent 批量处理恰好丢弃了第 2 步需要费力重建的上下文。「为什么永不--abort」见上文专节--abort丢弃解决工作、回到原样冲突、下次照旧。技能的适用前提是「merge 必然发生」决定「不应发生」要在调用之前做。技能在技能生态中的位置该技能被设计为随时可调用、无任何依赖的独立技能它在 git 卡住时启动在树干净且已提交时结束。它与周边技能的关系如下邻居diagnosing-bugs。这是它唯一的真正邻居——在「merge 干净地解决了、但合并后的代码行为异常」这个点上接管那是诊断问题不是冲突问题。diagnosing-bugs/SKILL.md 中 Phase 1「构建反馈循环」的方法论与本技能第 4 步「运行自动化检查」正好衔接merge 后若行为异常就要用「能对当前 bug 变红的紧致循环」去定位而不是靠读代码猜。地图ask-matt。该技能完全位于 idea-to-ship 主流程之外ask-matt/SKILL.md 是了解它前后应该运行什么技能的路由地图。工具层互补git-guardrails-claude-code。前者在方法上禁--abort后者在 hook 层拦截破坏性 git 命令共同约束 Agent 的 git 行为。从仓库的安装机制看所有技能包括本技能通过 scripts/link-skills.sh 以符号链接方式安装到~/.claude/skills和~/.agents/skills执行git pull即可同步更新无需手动复制。小结resolving-merge-conflicts的核心价值可以用一句话概括把「解决冲突」从文本拼接升级为「意图仲裁」。五步工作流看状态 → 找主来源 → 逐 hunk 解决并记录代价 → 跑自动化检查 → 完成提交把「不丢变更」与「不引入坏代码」两个目标分别绑定到第 2 步和第 4 步上同时用「绝不--abort」锁死逃避路径。它刻意只解决眼前这个冲突不越界处理两侧事务——真正的大规模重构时序问题、平行会话的合并归属问题由使用者按技能文档中的建议自行拿捏。对 Agent 而言这是一套可重复、可验证、可被验收清单检验的冲突解决协议对工程师而言这也是一份可以直接用于日常协作的冲突解决 checklist。参考路径技能本体skills/engineering/resolving-merge-conflicts/SKILL.md配套深度文档docs/engineering/resolving-merge-conflicts.mdAgent 元信息skills/engineering/resolving-merge-conflicts/agents/openai.yaml技能目录索引skills/engineering/README.md相邻技能skills/engineering/diagnosing-bugs/SKILL.md、skills/engineering/ask-matt/SKILL.md、skills/misc/git-guardrails-claude-code/SKILL.md安装机制scripts/link-skills.sh【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于 Git 冲突的意图式解决法：深入解析 resolving-merge-conflicts 技能
基于 Git 冲突的意图式解决法深入解析 resolving-merge-conflicts 技能【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills导读resolving-merge-conflicts是当前仓库skills13/skills中一个面向工程实践的核心技能专门用于处理正在进行的 git merge / rebase 冲突。它不把冲突当作文本拼接问题而是强调先追溯每一方变更的主来源primary source——提交信息、PR、原始 issue——再逐 hunk 解决冲突并在提交前跑完项目自身的自动化检查。读完本文你将掌握一套可复制的「五步冲突解决工作流」、为什么不能依赖--ours/--theirs按旗标盲解、以及为什么--abort在技能中被明令禁止。本文以 resolving-merge-conflicts/SKILL.md 及其配套文档 docs/engineering/resolving-merge-conflicts.md 为主体并结合仓库源码与相邻技能进行纵深印证。技能是什么定义与触发方式该技能在仓库中的正式定义位于 SKILL.md 的 frontmatter--- name: resolving-merge-conflicts description: Use when you need to resolve an in-progress git merge/rebase conflict. ---配套的 Agent 元信息位于 agents/openai.yamlinterface: display_name: Resolving Merge Conflicts short_description: Resolve merge and rebase conflicts在 skills/engineering/README.md 中它被归类为Model-invoked模型可自动调用的技能——这意味着只要任务匹配git 已在冲突处停下Agent 可以主动拾取它而不必等用户手动输入。触发方式有两种用户直接输入/resolving-merge-conflicts或当任务恰好匹配时Agent 自动调用该技能。它的适用边界非常明确git 已经停下、且自身无法解决的冲突。技能只针对眼前这一个冲突不越界处理冲突两侧的其它事务。你的处境应该用哪个技能正在 merge 或 rebase 中途工作区出现冲突标记本技能resolving-merge-conflictsMerge 已完成但合并后的代码行为异常、原因不明转向 diagnosing-bugs正在规划如何切分工作、让分支尽量少碰撞两者都不用见下文「平行工作」讨论五步核心工作流SKILL.md 给出了五个步骤这是整个技能的灵魂逐条拆解如下第 1 步看清当前状态先查看 merge/rebase 的当前状态检查 git 历史与发生冲突的文件。这一步建立事实基础——哪些文件冲突、冲突发生在哪个提交链上、当前处于 merge 还是 rebase 的中途。第 2 步为每个冲突找到主来源这是全技能的关键一步。对每一处冲突都要深入理解每一方变更为什么存在、原始意图是什么阅读提交信息commit message查看 PR 内容查阅原始 issue / ticket。只有在历史中完成这一轮追溯后才进入 diff。技能配套文档 docs/engineering/resolving-merge-conflicts.md 中有一句核心论断「你无法保留一个你尚未读过的意图。」You cannot preserve an intent you have not read.因此工作从历史开始而不是从差异开始。第 3 步逐 hunk 解决冲突解决每个冲突块时遵循三条铁律双方意图尽量都保留当两边的行为可以兼容时把两边的行为都合进来真正不可兼容时选择与本次 merge 既定目标一致的一侧并显式记录代价trade-off即明确注明丢弃了什么、为什么丢弃绝不发明新行为不为了掩盖冲突而凭空新增任何两边都不存在的代码。配套文档强调这一步拒绝「按旗标盲解」的失败模式——用--ours、--theirs或手工删掉看起来不重要的一块让冲突标记消失、让构建能编译通过。这种解决方式可能在语法上完美却会悄悄丢掉某个人有意做的变更。第 4 步发现并运行项目自身的自动化检查找到项目的自动化检查automated checks并运行典型顺序是先类型检查typecheck再测试tests最后格式化format。修复任何由合并引入的问题。配套文档点明了这一步的深层原因merge 是 git 中最容易产生「同时满足两个分支、却通不过任何一方测试」的代码的地方。因此检查必须在提交之前运行并通过而不是等你事后发现坏了才补跑。第 5 步完成 merge / rebaseStage 全部内容并提交commit如果正在 rebase则继续 rebase 过程直到所有提交都重放完毕——多提交 rebase 中剩余每个提交都要处理干净不能半途而废。为什么永远不用--abortSKILL.md 第 3 步明确写道Always resolve; never--abort。配套文档给出了完整论证Aborting throws away the resolution work and returns you to the same conflict, unchanged, the next time you try.即--abort会丢弃已经完成的全部解决工作下次尝试时你面对的还是同一个冲突一无所获。该技能是为「merge 必然要发生」的场景设计的如果你已经决定这次合并不应该发生那应该在调用本技能之前做这个决定而不是把它作为循环内的一个分支。这与本仓库中另一个技能 git-guardrails-claude-code 的安全理念形成互补后者通过 Claude Code 的 PreToolUse hook 拦截git push、git reset --hard、git clean -f、git branch -D等破坏性命令见 block-dangerous-git.sh从工具层防止 Agent 走危险捷径而resolving-merge-conflicts从方法论层禁止--abort这个逃避路径。两者都服务于同一个目标让 git 操作总是收敛到可提交、可验证的状态。主来源优先于ours/theirs配套文档用一个专节阐述了「主来源primary source」方法论「按旗标解决」是这项技能要消灭的失败模式。--ours / --theirs / 手工删掉看起来不重要的一块 → 冲突标记消失、构建编译通过 → 但某个人有意做的变更被静默丢弃解决之道在于解决者必须在动任何一个 hunk 之前把每一侧追溯回它的主来源——提交信息、PR、原始 issue——从而在两个意图之间做选择而不是在两段文本之间做选择。两者兼容就都保留不兼容就选与 merge 目标一致的一侧并命名代价绝不发明新行为来糊弄过去。配套文档还点出了第二步存在的另一个理由技能会找到仓库自己的自动化检查并在提交前运行。因为 merge 最容易产生「两边都满足、两边测试都过不了」的代码主来源追溯负责「不丢变更」自动化检查负责「不引入坏代码」。验证是否成功验收清单配套文档的「Its working if」给出了一组可操作的验收标准可以当作解决完成后的自检清单Agent 在解决冲突时会引用提交信息、PR 或 issue而不是只引用 diff hunk每个 hunk 最终要么保留双方行为要么带有一条显式说明标注丢弃了什么、为什么最终结果中没有出现两个分支上都不存在的新内容typecheck、tests、format 是在提交前定位并跑绿而不是等你发现坏了之后才补跑最终停在一个干净的工作区整个操作包括多提交 rebase 的剩余每个提交全部完成。常见问题与设计取舍「Claude Code 自己解决冲突已经不错了为什么还需要技能」附加价值在于「找主来源」和「跑反馈循环」这两步——否则它们每次都要靠人工提示。未经提示的 Agent 通常会只看 diff 就给出一个「看起来合理」的解决并停在那里。该技能的价值正是它不允许 Agent 跳过的两个步骤读懂每一侧为什么存在以及事后跑检查。配套文档坦率地承认这在优秀模型之上只是「薄薄的一层余量」甚至有读者预言随着模型变强这个技能最终可能变成空操作no-op——这是有意为之的边界克制。「要不要把平行 Agent 隔离到不同文件从源头避免冲突」大多数情况下不需要。把文件分区隔离给平行任务的成本大于收益因为 Agent 已经足够擅长解决冲突这个权衡并不像看上去那么苛刻。唯一值得保留的纪律是先做大规模重构。一个大型重命名落地后再有十个分支从它上面分叉这种情况才是真正昂贵的冲突来源。配套文档还记录了一个来自平行 worktree 用户报告的告诫当多个并行会话各自在自己的 tree 里完成一个 ticket 时合并回去最好由写下该变更的那个会话来做——因为只有它已经知道意图。把所有人的冲突最后堆给一个 Agent 批量处理恰好丢弃了第 2 步需要费力重建的上下文。「为什么永不--abort」见上文专节--abort丢弃解决工作、回到原样冲突、下次照旧。技能的适用前提是「merge 必然发生」决定「不应发生」要在调用之前做。技能在技能生态中的位置该技能被设计为随时可调用、无任何依赖的独立技能它在 git 卡住时启动在树干净且已提交时结束。它与周边技能的关系如下邻居diagnosing-bugs。这是它唯一的真正邻居——在「merge 干净地解决了、但合并后的代码行为异常」这个点上接管那是诊断问题不是冲突问题。diagnosing-bugs/SKILL.md 中 Phase 1「构建反馈循环」的方法论与本技能第 4 步「运行自动化检查」正好衔接merge 后若行为异常就要用「能对当前 bug 变红的紧致循环」去定位而不是靠读代码猜。地图ask-matt。该技能完全位于 idea-to-ship 主流程之外ask-matt/SKILL.md 是了解它前后应该运行什么技能的路由地图。工具层互补git-guardrails-claude-code。前者在方法上禁--abort后者在 hook 层拦截破坏性 git 命令共同约束 Agent 的 git 行为。从仓库的安装机制看所有技能包括本技能通过 scripts/link-skills.sh 以符号链接方式安装到~/.claude/skills和~/.agents/skills执行git pull即可同步更新无需手动复制。小结resolving-merge-conflicts的核心价值可以用一句话概括把「解决冲突」从文本拼接升级为「意图仲裁」。五步工作流看状态 → 找主来源 → 逐 hunk 解决并记录代价 → 跑自动化检查 → 完成提交把「不丢变更」与「不引入坏代码」两个目标分别绑定到第 2 步和第 4 步上同时用「绝不--abort」锁死逃避路径。它刻意只解决眼前这个冲突不越界处理两侧事务——真正的大规模重构时序问题、平行会话的合并归属问题由使用者按技能文档中的建议自行拿捏。对 Agent 而言这是一套可重复、可验证、可被验收清单检验的冲突解决协议对工程师而言这也是一份可以直接用于日常协作的冲突解决 checklist。参考路径技能本体skills/engineering/resolving-merge-conflicts/SKILL.md配套深度文档docs/engineering/resolving-merge-conflicts.mdAgent 元信息skills/engineering/resolving-merge-conflicts/agents/openai.yaml技能目录索引skills/engineering/README.md相邻技能skills/engineering/diagnosing-bugs/SKILL.md、skills/engineering/ask-matt/SKILL.md、skills/misc/git-guardrails-claude-code/SKILL.md安装机制scripts/link-skills.sh【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考