企业官网建设流程全解析

现在很多功能早已不只修改一个仓库。

一次“增加会员等级字段”的需求，可能同时涉及：

• 后端接口仓库；

• Web前端仓库；

• 移动端仓库；

• 公共SDK仓库；

• 部署配置仓库。

每个仓库单独看，修改似乎都没有问题；真正合并和发布时，却可能出现字段名称不一致、SDK版本没更新、配置项遗漏、前端提前上线等问题。

因此，多仓库项目最难的部分通常不是写代码，而是：

怎样在提交之前，把分散在不同仓库中的修改放到同一个功能视角下检查？

ChatGPT桌面端现在支持在多文件夹项目中查看多个Git仓库，并从Review入口检查各仓库的变更。配合Codex的代码审查能力，可以建立一套跨仓库Diff检查流程。

一、为什么逐个仓库Review容易漏问题？

假设一个功能涉及三个仓库：

shop-api shop-web shop-sdk

后端把接口返回字段从：

{ "memberLevel": "gold" }

修改成：

{ "membershipTier": "gold" }

单独审查后端仓库时，这个命名可能完全合理。

但如果前端仍然读取memberLevel，SDK类型定义也没有同步更新，三个仓库各自的代码可能都能通过局部检查，完整功能却会失败。

逐仓库审查容易遗漏四类问题：

1. 接口契约不一致；

2. 发布顺序不正确；

3. 版本和依赖没有同步；

4. 回退方案无法配套执行。

跨仓库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误读或误改无关项目的风险。

四、先建立“仓库权限矩阵”

多仓库任务开始前，应该明确每个仓库可以做什么。

例如：

可以直接告诉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 changes；

• Review against a base branch；

• Review a commit；

• Custom review instructions。

多仓库功能最适合增加一段自定义审查要求：

审查当前项目中全部仓库的变更。 不仅检查单个文件Bug，还要重点检查： 1. 接口字段和类型是否一致； 2. SDK版本与依赖是否同步； 3. 配置和环境变量是否遗漏； 4. 前后端兼容性； 5. 测试是否覆盖跨仓库调用； 6. 发布和回退顺序是否合理。 按P0、P1、P2输出问题， 不要修改代码。

七、完整案例：后端、SDK和前端联合修改

假设需求是：

在用户中心展示新的会员到期时间。

涉及三个仓库：

account-api account-sdk account-web

account-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。