git.mjs源码走读codex-plugin-cc如何解析审查目标与diff范围【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cccodex-plugin-cc是一个让 Claude Code 直接调用Codex 做代码审查code review或委派任务的插件。它的核心模块 git.mjs 负责两件关键事解析审查目标review 到底审什么和确定 diff 范围改动边界从哪里算起。本文带你快速读懂这两个机制无需深奥背景。先认识项目在 Claude Code 里跑 Codex 审查安装插件后你可以直接用斜杠命令启动审查/codex:review # 审查未提交改动或对比基准分支 /codex:review --base main这些命令的底层实现入口是 codex-companion.mjs它先调用resolveReviewTarget确定审什么再根据场景调用collectReviewContext收集改动的完整上下文。而所有 Git 相关的判断逻辑都集中在 git.mjs 这一个约 346 行的文件里。 想本地走读源码执行下面的命令即可git clone https://gitcode.com/GitHub_Trending/co/codex-plugin-cc解析审查目标resolveReviewTarget 的 4 步决策流核心函数 resolveReviewTarget 回答一个问题这次审查的目标是未提交的工作区还是某个分支相对基线的整体改动它的决策优先级git.mjs 中按顺序判断优先级条件结果1用户传了--base refbranch模式基线就是该 ref2用户传了--scope working-treeworking-tree模式只审未提交改动3--scope branch自动探测默认分支作为基线4默认auto工作区脏有改动→ 审工作区干净 → 审分支几个值得注意的细节默认分支探测detectDefaultBranch 先看origin/HEAD符号引用再依次尝试main、master、trunk本地和远端都查。都找不到时直接报错提示用户传--base ref或使用--scope working-tree——宁可明确失败也不瞎猜基线。脏的定义getWorkingTreeState 同时统计已暂存、未暂存、未跟踪三类文件任何一类非空即视为有可审内容。这就是为什么只新增了文件、没改任何旧文件也能触发工作区审查。每个返回结果都带explicit标记区分用户显式指定和自动推断方便后续命令做不同的校验与提示。确定 diff 范围merge-base 与两种 Git 区间记法当目标是分支审查时buildBranchComparison 只跑一条git merge-base HEAD base就推导出了三种范围merge-base两分支的共同祖先提交commitRange merge-base..HEAD双点只取我在本分支新增的提交不含基线后来发展的内容——这正是审查该用的范围reviewRange base...HEAD三点供git diff做三点比较含义相同但写法不同为什么要绕开直接base..HEAD因为如果基线分支在你开发期间又合入了新提交双点区间base..HEAD会把别人的提交也算进你的改动里审查就会冤枉你。用 merge-base 作为起点diff 范围永远精确等于你做的事。收集 diff 上下文大改动自动降级为轻量摘要collectReviewContext 拿到目标后要先判断diff 是直接内联喂给 Codex还是只给摘要让 Codex 自己读仓库由文件数 字节数双门槛决定git.mjs 的默认值常量默认值含义DEFAULT_INLINE_DIFF_MAX_FILES2改动文件数上限DEFAULT_INLINE_DIFF_MAX_BYTES256 KBdiff 输出字节上限MAX_UNTRACKED_BYTES24 KB单个未跟踪文件的内容上限达标 →inputMode: inline-diff完整 diff 写进提示词指引语为以下仓库上下文是主要证据buildAdversarialCollectionGuidance。超标 →inputMode: self-collect只给提交日志、diff 统计、变更文件列表并提示 Codex 用只读 git 命令自行检查目标 diff避免超长提示词撑爆上下文。两个工程细节值得品味字节数测量技巧measureGitOutputBytes 把maxBuffer设为上限1一旦捕获ENOBUFS输出缓冲溢出就断定超限无需真的读完整份巨型 diff——省内存又省时。未跟踪文件的安全处理formatUntrackedFile 对目录、损坏的符号链接、二进制文件靠 isProbablyText 探测 NUL 字节逐一优雅跳过并标注原因绝不因一个奇怪的未跟踪文件让整个审查崩溃。用测试验证理解10 个用例覆盖全部分支逻辑读完源码最推荐的巩固方式是跑一遍 tests/git.test.mjs——它在临时目录里真实初始化 Git 仓库逐条验证上面的行为脏仓库优先审工作区、干净仓库回退到分支 diff--base显式覆盖、探测不到默认分支时报错小改动保持内联 diff、大改动降级为 self-collect、超大单文件 diff 降级配合 review.md 里的参数说明--wait/--background/--base/--scope你对/codex:review每个行为的底层出处都能对号入座。小结git.mjs 的三行设计哲学 目标解析显式参数永远优先自动推断只做兜底推断不出就明确报错 范围计算一切以 merge-base 为起点diff 范围精确等于你做的改动 上下文分级小改动全量内联大改动轻量摘要 让 Codex 自行取证永远不撑爆提示词理解这条目标 → 范围 → 上下文的流水线你就掌握了 codex-plugin-cc 审查能力的地基。【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 git.mjs源码走读：codex-plugin-cc如何解析审查目标与diff范围
git.mjs源码走读codex-plugin-cc如何解析审查目标与diff范围【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cccodex-plugin-cc是一个让 Claude Code 直接调用Codex 做代码审查code review或委派任务的插件。它的核心模块 git.mjs 负责两件关键事解析审查目标review 到底审什么和确定 diff 范围改动边界从哪里算起。本文带你快速读懂这两个机制无需深奥背景。先认识项目在 Claude Code 里跑 Codex 审查安装插件后你可以直接用斜杠命令启动审查/codex:review # 审查未提交改动或对比基准分支 /codex:review --base main这些命令的底层实现入口是 codex-companion.mjs它先调用resolveReviewTarget确定审什么再根据场景调用collectReviewContext收集改动的完整上下文。而所有 Git 相关的判断逻辑都集中在 git.mjs 这一个约 346 行的文件里。 想本地走读源码执行下面的命令即可git clone https://gitcode.com/GitHub_Trending/co/codex-plugin-cc解析审查目标resolveReviewTarget 的 4 步决策流核心函数 resolveReviewTarget 回答一个问题这次审查的目标是未提交的工作区还是某个分支相对基线的整体改动它的决策优先级git.mjs 中按顺序判断优先级条件结果1用户传了--base refbranch模式基线就是该 ref2用户传了--scope working-treeworking-tree模式只审未提交改动3--scope branch自动探测默认分支作为基线4默认auto工作区脏有改动→ 审工作区干净 → 审分支几个值得注意的细节默认分支探测detectDefaultBranch 先看origin/HEAD符号引用再依次尝试main、master、trunk本地和远端都查。都找不到时直接报错提示用户传--base ref或使用--scope working-tree——宁可明确失败也不瞎猜基线。脏的定义getWorkingTreeState 同时统计已暂存、未暂存、未跟踪三类文件任何一类非空即视为有可审内容。这就是为什么只新增了文件、没改任何旧文件也能触发工作区审查。每个返回结果都带explicit标记区分用户显式指定和自动推断方便后续命令做不同的校验与提示。确定 diff 范围merge-base 与两种 Git 区间记法当目标是分支审查时buildBranchComparison 只跑一条git merge-base HEAD base就推导出了三种范围merge-base两分支的共同祖先提交commitRange merge-base..HEAD双点只取我在本分支新增的提交不含基线后来发展的内容——这正是审查该用的范围reviewRange base...HEAD三点供git diff做三点比较含义相同但写法不同为什么要绕开直接base..HEAD因为如果基线分支在你开发期间又合入了新提交双点区间base..HEAD会把别人的提交也算进你的改动里审查就会冤枉你。用 merge-base 作为起点diff 范围永远精确等于你做的事。收集 diff 上下文大改动自动降级为轻量摘要collectReviewContext 拿到目标后要先判断diff 是直接内联喂给 Codex还是只给摘要让 Codex 自己读仓库由文件数 字节数双门槛决定git.mjs 的默认值常量默认值含义DEFAULT_INLINE_DIFF_MAX_FILES2改动文件数上限DEFAULT_INLINE_DIFF_MAX_BYTES256 KBdiff 输出字节上限MAX_UNTRACKED_BYTES24 KB单个未跟踪文件的内容上限达标 →inputMode: inline-diff完整 diff 写进提示词指引语为以下仓库上下文是主要证据buildAdversarialCollectionGuidance。超标 →inputMode: self-collect只给提交日志、diff 统计、变更文件列表并提示 Codex 用只读 git 命令自行检查目标 diff避免超长提示词撑爆上下文。两个工程细节值得品味字节数测量技巧measureGitOutputBytes 把maxBuffer设为上限1一旦捕获ENOBUFS输出缓冲溢出就断定超限无需真的读完整份巨型 diff——省内存又省时。未跟踪文件的安全处理formatUntrackedFile 对目录、损坏的符号链接、二进制文件靠 isProbablyText 探测 NUL 字节逐一优雅跳过并标注原因绝不因一个奇怪的未跟踪文件让整个审查崩溃。用测试验证理解10 个用例覆盖全部分支逻辑读完源码最推荐的巩固方式是跑一遍 tests/git.test.mjs——它在临时目录里真实初始化 Git 仓库逐条验证上面的行为脏仓库优先审工作区、干净仓库回退到分支 diff--base显式覆盖、探测不到默认分支时报错小改动保持内联 diff、大改动降级为 self-collect、超大单文件 diff 降级配合 review.md 里的参数说明--wait/--background/--base/--scope你对/codex:review每个行为的底层出处都能对号入座。小结git.mjs 的三行设计哲学 目标解析显式参数永远优先自动推断只做兜底推断不出就明确报错 范围计算一切以 merge-base 为起点diff 范围精确等于你做的改动 上下文分级小改动全量内联大改动轻量摘要 让 Codex 自行取证永远不撑爆提示词理解这条目标 → 范围 → 上下文的流水线你就掌握了 codex-plugin-cc 审查能力的地基。【免费下载链接】codex-plugin-ccUse Codex from Claude Code to review code or delegate tasks.项目地址: https://gitcode.com/GitHub_Trending/co/codex-plugin-cc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考