Codex实战教程：多仓库项目怎么一次Review全部Diff？跨仓库改动检查流程

现在很多功能早已不只修改一个仓库。一次“增加会员等级字段”的需求可能同时涉及后端接口仓库Web前端仓库移动端仓库公共SDK仓库部署配置仓库。每个仓库单独看修改似乎都没有问题真正合并和发布时却可能出现字段名称不一致、SDK版本没更新、配置项遗漏、前端提前上线等问题。因此多仓库项目最难的部分通常不是写代码而是怎样在提交之前把分散在不同仓库中的修改放到同一个功能视角下检查ChatGPT桌面端现在支持在多文件夹项目中查看多个Git仓库并从Review入口检查各仓库的变更。配合Codex的代码审查能力可以建立一套跨仓库Diff检查流程。一、为什么逐个仓库Review容易漏问题假设一个功能涉及三个仓库shop-api shop-web shop-sdk后端把接口返回字段从{ memberLevel: gold }修改成{ membershipTier: gold }单独审查后端仓库时这个命名可能完全合理。但如果前端仍然读取memberLevelSDK类型定义也没有同步更新三个仓库各自的代码可能都能通过局部检查完整功能却会失败。逐仓库审查容易遗漏四类问题接口契约不一致发布顺序不正确版本和依赖没有同步回退方案无法配套执行。跨仓库Review的目标不是把几个Diff简单放在一起而是确认这些修改能不能作为一个完整功能共同交付二、多仓库Review能做什么当一个本地项目包含多个文件夹并且这些文件夹分别属于不同Git仓库时桌面端会识别每个仓库的修改状态。在Review区域中可以看到项目里有哪些仓库每个仓库增加和删除了多少行哪些文件发生了变化当前查看的是未暂存、已暂存、提交还是分支Diff不同仓库中的具体修改内容。你还可以对具体代码行添加评论再把评论交给Codex继续处理。但要注意多仓库项目只是统一了查看和分析入口并没有把多个Git仓库变成一个仓库。每个仓库仍然拥有自己的Git历史当前分支基础分支提交记录Pull Request发布流程。所以统一Review之后仍然需要分别提交、推送和创建PR。三、怎样创建多文件夹项目首先把参与当前功能的仓库准备在本地。例如workspace/ ├── shop-api/ ├── shop-web/ ├── shop-sdk/ └── deploy-config/然后在ChatGPT桌面端创建或打开本地项目把这些仓库文件夹加入同一个多文件夹项目。加入前建议先检查每个目录git -C shop-api status git -C shop-web status git -C shop-sdk status git -C deploy-config status这样可以确认当前分支是否正确是否混入其他任务的未提交修改是否存在未追踪文件是否有仓库处于冲突状态。不要把所有开发目录直接加入项目。只加入本次功能真正需要的仓库能够减少上下文噪声也能降低Codex误读或误改无关项目的风险。四、先建立“仓库权限矩阵”多仓库任务开始前应该明确每个仓库可以做什么。例如仓库用途权限shop-api修改接口与业务逻辑可读写shop-web修改页面调用可读写shop-sdk检查类型与版本先只读deploy-config检查环境变量只读可以直接告诉Codex本项目包含四个仓库。 允许修改 - shop-api - shop-web 默认只读 - shop-sdk - deploy-config 如果判断必须修改只读仓库 先说明原因、影响范围和建议方案不要直接修改。这一步很重要。因为Codex能够看到多个仓库并不等于它应该同时修改全部仓库。五、怎样让Codex先建立跨仓库变更清单不要一开始就让Codex直接Review。先让它确认各仓库在当前功能中的角色请分析当前多文件夹项目中的全部Git仓库。 目标 确认“新增会员等级展示”涉及的跨仓库修改是否完整。 先不要修改代码。 请输出 1. 每个仓库的当前分支 2. 每个仓库的修改文件 3. 各仓库在本功能中的职责 4. 仓库之间的数据或依赖关系 5. 预计需要重点检查的集成风险。理想输出应该类似shop-api 职责返回会员等级字段 变更接口DTO、序列化测试 shop-sdk 职责提供前端类型定义 变更当前没有修改可能遗漏 shop-web 职责展示会员等级 变更页面组件、请求适配层 deploy-config 职责本功能不需要修改 变更无这一步往往能在正式Review之前发现遗漏仓库。六、怎样在Review面板检查全部Diff打开项目的Review入口后先观察仓库列表和每个仓库的修改行数。建议按照下面的顺序检查。第一步检查修改范围先确认哪个仓库出现了计划外修改。例如部署仓库本来应该只读却出现了配置文件变化应立即追问原因。第二步选择Diff范围常用范围包括Unstaged未暂存修改Staged已经加入暂存区的修改Last turn最近一轮Agent产生的修改Commit指定提交Branch当前分支相对基础分支的完整差异。如果当前工作区混有人工修改和Codex修改不能只看Last turn。最终提交前应该检查完整工作区或分支Diff。第三步运行独立Review可以输入/review然后根据情况选择Review uncommitted changesReview against a base branchReview a commitCustom review instructions。多仓库功能最适合增加一段自定义审查要求审查当前项目中全部仓库的变更。 不仅检查单个文件Bug还要重点检查 1. 接口字段和类型是否一致 2. SDK版本与依赖是否同步 3. 配置和环境变量是否遗漏 4. 前后端兼容性 5. 测试是否覆盖跨仓库调用 6. 发布和回退顺序是否合理。 按P0、P1、P2输出问题 不要修改代码。七、完整案例后端、SDK和前端联合修改假设需求是在用户中心展示新的会员到期时间。涉及三个仓库account-api account-sdk account-webaccount-api新增字段{ membershipExpiresAt: 2026-12-31T00:00:00Z }account-sdk增加类型定义export interface UserProfile { membershipExpiresAt?: string; }account-web读取字段并格式化展示。单独看三个Diff都可能正确但跨仓库Review还应该检查以下问题。字段是否完全一致检查membershipExpiresAt有没有在某个仓库写成memberExpiresAt是否需要保持兼容如果后端与前端不能同时发布前端是否能处理字段暂时不存在的情况SDK是否把字段设计成可选以支持灰度发布期间的新旧接口时间格式是否统一后端输出UTC时间前端是否按照用户时区显示有没有直接对字符串截取导致不同时区出现日期偏差SDK版本是否更新修改类型之后是否更新版本号并发布前端仓库的依赖版本是否已经指向包含新字段的SDK发布顺序是否正确合理顺序可能是后端兼容字段上线 → 发布新版SDK → 前端升级SDK → 前端展示功能上线如果前端先上线而后端字段还不存在页面必须具备降级显示。这就是跨仓库Review与普通代码审查最大的区别它不仅看代码对不对还要看系统能不能按照现实顺序上线。八、跨仓库Review必须检查哪些内容建议固定检查六条主线。1. 接口契约检查字段名称字段类型必填与可选默认值错误码序列化格式。2. 依赖和版本检查SDK版本包管理锁文件内部依赖地址API版本生成代码是否更新。3. 配置同步检查环境变量Feature Flag权限配置部署参数不同环境的默认值。4. 测试覆盖单仓库测试通过不代表跨仓库功能通过。至少应该确认后端契约测试SDK类型或生成测试前端组件测试关键集成流程兼容旧版本的降级测试。5. 发布顺序每个仓库什么时候发布是否允许独立发布哪个步骤失败后必须停止后续发布6. 回退顺序如果前端已经使用新字段而后端直接回退会不会导致页面报错跨仓库回退通常不能简单地按照发布顺序倒放必须提前验证兼容窗口。九、怎样防止其他任务的Diff混进来Review面板展示的是Git仓库当前状态不只包括Codex修改也可能包括开发者手动修改和之前遗留的文件。因此开始任务前应确保每个仓库使用独立功能分支工作区没有其他任务的未提交文件大型并行任务使用Worktree隔离每轮修改后检查Last turn最终交付前检查完整Branch Diff。如果发现无关修改不要让Codex直接“顺便处理”。先确认它属于当前任务另一个未完成任务自动格式化生成文件本地环境变化。不同来源的修改应尽量拆成不同提交或不同分支。十、怎样设计跨仓库提交和回退顺序完成Review后可以要求Codex输出交付清单根据当前全部仓库的最终Diff 生成跨仓库交付计划。 每个仓库说明 1. 分支名称 2. 修改目的 3. 必须通过的测试 4. 前置依赖 5. 推荐提交信息 6. PR合并顺序 7. 发布顺序 8. 回退条件和回退顺序。一个合理结果可能是1. account-api 先合并保持新旧客户端兼容。 2. account-sdk 接口上线后发布新版本。 3. account-web 升级SDK并开启展示功能。 回退 先关闭前端Feature Flag 再回退前端版本 最后判断是否需要回退API。不要让多个仓库同时合并、同时发布却没有负责人和停止条件。十一、可直接复制的多仓库Review模板目标 审查当前多文件夹项目中与【功能名称】有关的全部Diff。 涉及仓库 - 【仓库A】作用和权限 - 【仓库B】作用和权限 - 【仓库C】作用和权限 基础分支 - 【仓库A】main - 【仓库B】develop - 【仓库C】main 重点检查 1. 各仓库修改是否符合任务范围 2. 接口字段、类型和错误码是否一致 3. SDK、依赖和版本是否同步 4. 配置与环境变量是否遗漏 5. 跨仓库测试是否完整 6. 新旧版本是否兼容 7. 发布顺序是否安全 8. 回退顺序是否可执行 9. 是否存在无关Diff。 输出 - 各仓库变更摘要 - P0/P1/P2问题 - 遗漏修改 - 必须补充的测试 - 合并与发布顺序 - 回退方案。 本轮只审查不修改代码。十二、发布前最终检查表□ 已确认每个仓库的当前分支 □ 已清除其他任务的未提交修改 □ 已检查所有仓库的完整Diff □ 接口字段和类型完全一致 □ SDK版本和依赖已经同步 □ 配置与环境变量没有遗漏 □ 单仓库测试全部通过 □ 跨仓库集成流程已经验证 □ 新旧版本具备兼容窗口 □ 合并和发布顺序已经确定 □ 回退顺序和停止条件已经明确 □ 每个仓库都有对应负责人结语多仓库项目最危险的情况不是某个仓库代码写错而是每个仓库单独看都正确放到一起却无法工作。ChatGPT桌面端的多文件夹项目和跨仓库Review入口可以把分散的Git变更放在同一个项目视角下检查。但工具只负责展示Diff。真正可靠的跨仓库审查还需要开发者主动检查接口契约、依赖版本、配置同步、测试覆盖、发布顺序和回退路径。一套完整流程应该是建立多文件夹项目→ 明确仓库权限→ 输出变更清单→ 统一检查全部Diff→ 运行独立Review→ 验证跨仓库契约→ 制定合并与发布顺序→ 确认回退方案。当一次需求开始涉及前端、后端、SDK和配置仓库时不要再把它当成几个互不相关的Pull Request。它们共同组成的是一个交付单元也应该接受一次完整的系统级Review。