Skip to main content
Glama

resolve_conflict

Analyze and resolve Git merge conflicts by processing conflict content to restore code functionality.

Instructions

【Git 冲突解决】分析并解决 Git 冲突

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
conflictsNo冲突内容(git diff 或冲突文件内容)

Implementation Reference

  • The core handler function `resolveConflict` that generates a comprehensive Markdown guide for resolving Git merge conflicts, including analysis steps, examples, strategies, and prevention tips based on the provided `args.conflicts`.
    export async function resolveConflict(args: any) {
      try {
        const conflicts = args?.conflicts || "";
    
        const message = `请分析并解决以下 Git 冲突:
    
    ⚔️ **冲突内容**:
    ${conflicts || "请提供 git diff 或冲突文件内容"}
    
    ---
    
    ## Git 冲突解决流程
    
    ### 第一步:识别冲突
    
    执行以下命令查看冲突:
    \`\`\`bash
    # 查看冲突文件列表
    git status
    
    # 查看具体冲突
    git diff
    
    # 或查看单个文件冲突
    git diff --ours --theirs filename
    \`\`\`
    
    ### 第二步:理解冲突标记
    
    **冲突格式:**
    \`\`\`
    <<<<<<< HEAD (当前分支)
    你的修改
    =======
    他人的修改
    >>>>>>> branch-name (合并的分支)
    \`\`\`
    
    **示例冲突:**
    \`\`\`javascript
    function calculateTotal(items) {
    <<<<<<< HEAD
      // 你的修改:添加了折扣
      const subtotal = items.reduce((sum, item) => sum + item.price, 0);
      return subtotal * 0.9; // 10% 折扣
    =======
      // 他人的修改:添加了税费
      const subtotal = items.reduce((sum, item) => sum + item.price * item.quantity, 0);
      return subtotal * 1.1; // 10% 税费
    >>>>>>> feature/add-tax
    }
    \`\`\`
    
    ---
    
    ## 冲突分析
    
    ### 🔍 冲突类型识别
    
    **1️⃣ 简单冲突(二选一)**
    - 两个分支修改了同一行
    - 通常选择其中一个版本
    
    **2️⃣ 复杂冲突(需要合并)**
    - 两个分支都添加了有用的功能
    - 需要整合双方的修改
    
    **3️⃣ 语义冲突**
    - 语法上没冲突,但逻辑上不兼容
    - 需要重新设计
    
    **4️⃣ 结构冲突**
    - 文件被移动或删除
    - 需要决定文件的最终状态
    
    ---
    
    ## 解决策略
    
    ### 策略 1:保留当前分支(ours)
    \`\`\`bash
    git checkout --ours filename
    git add filename
    \`\`\`
    
    ### 策略 2:保留对方分支(theirs)
    \`\`\`bash
    git checkout --theirs filename
    git add filename
    \`\`\`
    
    ### 策略 3:手动合并(推荐)
    
    **步骤:**
    1. 分析双方的修改意图
    2. 整合有价值的修改
    3. 删除冲突标记
    4. 测试合并后的代码
    
    **合并示例:**
    \`\`\`javascript
    // 原始冲突
    function calculateTotal(items) {
    <<<<<<< HEAD
      const subtotal = items.reduce((sum, item) => sum + item.price, 0);
      return subtotal * 0.9; // 10% 折扣
    =======
      const subtotal = items.reduce((sum, item) => sum + item.price * item.quantity, 0);
      return subtotal * 1.1; // 10% 税费
    >>>>>>> feature/add-tax
    }
    
    // ✅ 合并后(整合双方修改)
    function calculateTotal(items, { discount = 0, taxRate = 0.1 } = {}) {
      // 整合了数量计算(theirs)和参数化设计(改进)
      const subtotal = items.reduce((sum, item) => sum + item.price * item.quantity, 0);
      const afterDiscount = subtotal * (1 - discount);
      return afterDiscount * (1 + taxRate);
    }
    \`\`\`
    
    ---
    
    ## 常见冲突场景
    
    ### 场景 1:Import 语句冲突
    \`\`\`typescript
    <<<<<<< HEAD
    import { Button, Input } from './components';
    import { api } from './services';
    =======
    import { Button, Select } from './components';
    import { fetchData } from './utils';
    >>>>>>> feature/add-select
    
    // ✅ 合并后
    import { Button, Input, Select } from './components';
    import { api } from './services';
    import { fetchData } from './utils';
    \`\`\`
    
    ### 场景 2:配置文件冲突
    \`\`\`json
    <<<<<<< HEAD
    {
      "name": "my-app",
      "version": "1.2.0",
      "scripts": {
        "dev": "vite",
        "build": "vite build"
      }
    }
    =======
    {
      "name": "my-app",
      "version": "1.1.0",
      "scripts": {
        "dev": "vite",
        "build": "vite build",
        "test": "jest"
      }
    }
    >>>>>>> feature/add-tests
    
    // ✅ 合并后(保留最新版本号和所有脚本)
    {
      "name": "my-app",
      "version": "1.2.0",
      "scripts": {
        "dev": "vite",
        "build": "vite build",
        "test": "jest"
      }
    }
    \`\`\`
    
    ### 场景 3:函数重构冲突
    \`\`\`typescript
    <<<<<<< HEAD
    // 你将同步改为异步
    async function getUserData(id) {
      const response = await fetch(\`/api/users/\${id}\`);
      return response.json();
    }
    =======
    // 他人添加了缓存
    function getUserData(id) {
      if (cache.has(id)) {
        return cache.get(id);
      }
      const data = fetchUser(id);
      cache.set(id, data);
      return data;
    }
    >>>>>>> feature/add-cache
    
    // ✅ 合并后(异步 + 缓存)
    async function getUserData(id) {
      if (cache.has(id)) {
        return cache.get(id);
      }
      const response = await fetch(\`/api/users/\${id}\`);
      const data = await response.json();
      cache.set(id, data);
      return data;
    }
    \`\`\`
    
    ---
    
    ## 解决步骤
    
    ### Step 1: 备份
    \`\`\`bash
    # 创建备份分支
    git branch backup-before-merge
    \`\`\`
    
    ### Step 2: 分析冲突
    \`\`\`bash
    # 查看冲突统计
    git diff --stat
    
    # 使用可视化工具
    git mergetool
    \`\`\`
    
    ### Step 3: 解决冲突
    1. 打开冲突文件
    2. 分析双方修改
    3. 手动合并代码
    4. 删除冲突标记(<<<, ===, >>>)
    
    ### Step 4: 测试
    \`\`\`bash
    # 运行测试
    npm test
    
    # 运行 linter
    npm run lint
    
    # 构建检查
    npm run build
    \`\`\`
    
    ### Step 5: 提交
    \`\`\`bash
    # 标记冲突已解决
    git add .
    
    # 完成合并
    git commit
    
    # Git 会自动生成合并消息,或自定义:
    git commit -m "chore: 解决 feature/xxx 合并冲突
    
    - 整合了折扣和税费计算
    - 保留了所有新增功能
    - 所有测试通过"
    \`\`\`
    
    ---
    
    ## 预防冲突
    
    ### 1️⃣ 频繁同步
    \`\`\`bash
    # 每天同步主分支
    git fetch origin
    git rebase origin/main
    \`\`\`
    
    ### 2️⃣ 小步提交
    - 提交粒度要小
    - 功能尽量独立
    - 避免大范围重构
    
    ### 3️⃣ 代码审查
    - PR 及时 Review
    - 避免长期未合并的分支
    
    ### 4️⃣ 使用工具
    - VSCode Git Lens
    - GitKraken
    - Sourcetree
    
    ---
    
    ## 复杂冲突处理
    
    ### 使用 Git Rerere(重用已记录的解决方案)
    \`\`\`bash
    # 启用 rerere
    git config --global rerere.enabled true
    
    # Git 会记住你的冲突解决方式
    # 下次遇到相同冲突时自动应用
    \`\`\`
    
    ### 使用三路合并工具
    \`\`\`bash
    # 配置 VSCode 作为合并工具
    git config --global merge.tool vscode
    git config --global mergetool.vscode.cmd 'code --wait $MERGED'
    
    # 使用
    git mergetool
    \`\`\`
    
    ---
    
    现在请分析冲突内容,提供:
    1. 冲突原因分析
    2. 双方修改意图
    3. 推荐的合并方案
    4. 完整的解决后代码`;
    
        return {
          content: [
            {
              type: "text",
              text: message,
            },
          ],
        };
      } catch (error) {
        const errorMessage =
          error instanceof Error ? error.message : String(error);
        return {
          content: [
            {
              type: "text",
              text: `❌ 冲突解决失败: ${errorMessage}`,
            },
          ],
          isError: true,
        };
      }
    }
  • The input schema definition for the 'resolve_conflict' tool, specifying the expected 'conflicts' parameter as a string.
      name: "resolve_conflict",
      description: "【Git 冲突解决】分析并解决 Git 冲突",
      inputSchema: {
        type: "object",
        properties: {
          conflicts: {
            type: "string",
            description: "冲突内容(git diff 或冲突文件内容)",
          },
        },
        required: [],
      },
    },
  • src/index.ts:507-508 (registration)
    Registration in the tool dispatcher switch statement, mapping the tool name to the resolveConflict handler invocation.
    case "resolve_conflict":
      return await resolveConflict(args);
  • Re-export of the resolveConflict handler from its implementation file, allowing import in src/index.ts.
    export { resolveConflict } from "./resolve_conflict.js";
  • src/index.ts:14-14 (registration)
    Import statement in src/index.ts that brings in the resolveConflict function from './tools/index.js' for use in the server.
    fix, gensql, resolveConflict, genui, explain, convert, genreadme, split, analyzeProject
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions '分析并解决' (analyze and resolve), implying it performs both analysis and resolution actions, but doesn't specify what '解决' entails (e.g., automatic merging, manual intervention, or outputting resolutions). It lacks details on permissions, side effects, or output format, which is a significant gap for a tool that likely modifies code.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise—just one sentence in Chinese—and front-loaded with the core purpose. There's no wasted text, making it efficient. However, it could be slightly more structured (e.g., separating analysis and resolution aspects) for better clarity, preventing a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a Git conflict resolution tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., resolved code, status messages), how it handles errors, or any behavioral nuances. This leaves significant gaps for an AI agent to understand the tool's full context and usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the single parameter 'conflicts' documented as '冲突内容(git diff 或冲突文件内容)' (conflict content, git diff or conflict file content). The description doesn't add any meaning beyond this, such as examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear purpose: '分析并解决 Git 冲突' (analyze and resolve Git conflicts). It specifies both the action (analyze and resolve) and the resource (Git conflicts). However, it doesn't explicitly distinguish this tool from sibling tools like 'fix' or 'refactor' that might also handle code issues, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There are no explicit instructions on when it's appropriate (e.g., after a merge conflict) or when not to use it (e.g., for non-Git issues). It also doesn't mention any prerequisites or compare it to sibling tools like 'fix' or 'refactor', leaving usage ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mybolide/mcp-probe-kit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server