conflictfix

conflictfix

合并冲突已经存在，而对于其中的每个冲突块，问题都很明确：它能否通过机械方式解决，还是需要人工查看？ conflictfix 会逐个冲突块给出判断。你需要提供文件路径，以及每个冲突块所依据的三方合并中的三组行列表——共同祖先的行（base）、你这边的行（ours）和对方的行（theirs）——它会为每个冲突块分类：对安全的冲突块返回解决后的行，并让有风险的冲突块保持原样。

有四类冲突块是安全的。如果 ours 和 theirs 完全相同，则该冲突块为 identical，解决结果就是这些行，不论它们与 base 有何不同。如果只有一方有变更——ours 仍与 base 相同，则该冲突块为 theirs_only，解决结果为 theirs；或者 theirs 仍与 base 相同，则该冲突块为 ours_only，解决结果为 ours——那么有变更的一方会直接胜出，包括删除所有行的情况。如果两边仅在空白字符上不同，则该冲突块为 whitespace_only，解决结果为原样返回的 ours，包括其中所有空格：规范化只用于判定类别，不会改写行。其他情况都属于 conflict：不安全，解决结果为 null，此工具绝不会自动合并。

检查按固定顺序进行，且首次匹配即生效，因此，如果三组列表完全一致，该冲突块会被判定为 identical，而不是 ours_only；如果单边变更同时在空白字符规范化后相同，则会报告为单边变更。空白字符规范化会修剪每一行，删除修剪后为空的开头和结尾条目，并用换行符连接剩余内容。此过程会保留内部空行，因此，如果一方仅在中间位置出现空行，这就是真正的差异，该冲突块属于 conflict，而不是空白字符差异。

结果会回显 path，为每个输入冲突块提供一个条目，包含从 0 开始的 index、class、safe 标志和 resolution，并汇总结果：safe_count、risky_count 和 fully_resolvable。仅当没有任何有风险的冲突块时，fully_resolvable 才为 true。格式错误的输入——path 缺失、为空或不是字符串，hunks 列表缺失、不是数组或为空，冲突块不是对象，base、ours 或 theirs 缺失或不是数组，或者任意一行不是字符串——会触发校验错误，并指出出错路径，例如 hunks[2].ours[0] must be a string；不会返回部分结果。未知的额外字段会被忽略，包括冲突块条目中的字段。此计算是纯本地操作：不会读取仓库，不会执行合并，也不会触碰任何文件。

CLI

npx @reneturcios/conflictfix triage --input args.json
npx @reneturcios/conflictfix --version

args.json 包含完整的参数对象：

{
  "path": "src/app.ts",
  "hunks": [
    {
      "base": ["const x = 1;"],
      "ours": ["const x = 1;"],
      "theirs": ["const x = 2;"]
    },
    {
      "base": ["return a;"],
      "ours": ["return b;"],
      "theirs": ["return c;"]
    }
  ]
}

结果以 JSON 格式打印：

{
  "path": "src/app.ts",
  "hunks": [
    {
      "index": 0,
      "class": "theirs_only",
      "safe": true,
      "resolution": ["const x = 2;"]
    },
    {
      "index": 1,
      "class": "conflict",
      "safe": false,
      "resolution": null
    }
  ],
  "safe_count": 1,
  "risky_count": 1,
  "fully_resolvable": false
}

退出代码：成功时为 0，运行时错误时为 1（包括输入文件无法读取或无效，以及输入无效），用法错误时为 2。

MCP server

npx -y @reneturcios/conflictfix mcp

MCP 客户端配置：

{
  "mcpServers": {
    "conflictfix": {
      "command": "npx",
      "args": ["-y", "@reneturcios/conflictfix", "mcp"]
    }
  }
}

工具

• triage_conflicts — 评估三方合并冲突：根据调用方提供的 base、ours 和 theirs 行，将每个冲突块分类为安全的机械式解决或有风险。安全的冲突块会返回解决后的行；有风险的冲突块绝不会自动合并。

  • path（字符串，必填，非空）——冲突块所属的文件路径
  • hunks（数组，必填，至少 1 项）——待评估的冲突块；每项包含：
    • base（字符串数组，必填，可为空）——共同祖先中的行
    • ours（字符串数组，必填，可为空）——我方的行
    • theirs（字符串数组，必填，可为空）——对方的行

  返回 {path, hunks, safe_count, risky_count, fully_resolvable}，其中 hunks 中的每个条目为 {index, class, safe, resolution}，class 的值为 identical、theirs_only、ours_only、 whitespace_only 或 conflict。

Docker

docker run -i ghcr.io/cloudcorprecords/conflictfix
docker run --rm -v "$PWD:/w" ghcr.io/cloudcorprecords/conflictfix triage --input /w/args.json

开发

npm install
npm run build   # tsc -> dist/
npm test        # tsx --test test/*.test.ts (pure local, no network)
npm run dev     # run the CLI from source

许可证

MIT — 版权所有 (c) 2026 Rene Turcios