生活分享

平行工作后的整合与验收

依档案与介面契约整合独立修改，处理冲突，再验证合并后的整体行为。

阅读时间约 20 分钟 · 操作 30 分钟

原创流程示意图，非产品界面截图。
图片：Mokaair (© Mokaair)
回总目录：Codex 学习中心：完整教程目录

进阶 · Desktop / CLI / VS Code / JetBrains

本篇目录
  1. 目标与准备
  2. 步骤 1：建立共同验收材料
  3. 步骤 2：分配两份互不覆写的交付
  4. 步骤 3：保存后依序整合
  5. 步骤 4：刻意制造冲突并中止
  6. 收尾、常见问题与交付

目标与准备

本段提到的教学与资源: ·

平行工作节省的是可以独立完成的时间，最后的整合仍有顺序。两个工作者都说完成，可能只是各自的分支完成；同一页同时用到两个变更时，还要在相同版本与环境重跑验收。这篇用标题与页尾两个文字档代表两份交付，不把简单文字测试宣称成整个网站测试。学会流程后，再套用到你专案真正的建置与浏览器检查。

步骤 1：建立共同验收材料

在自己练习区用档案管理员建立全新 integration-lab，再于此目录开启终端机。Windows、macOS、Linux 的下列 Git／Node 命令相同；先核对路径，并确认旁边没有本篇要用的 integration-heading、integration-footer、integration-review、integration-conflict 同名资料夹。若名称已存在就另选一组名称，所有后续步骤一致替换，不覆盖原工作。

新 integration-lab 终端机：仅设定这个练习库 · sh
git init -b main
git config user.name "Codex Learner"
git config user.email "learner@example.test"

用编辑器建立下列三个完整档案。heading.txt 初始为 Title: Small Steps，footer.txt 初始为 Footer: Local exercise，各自保留最后换行。测试描述的是两项尚未完成的新要求，所以基准执行刻意是零通过、两失败；这是没有远端的独立教材，不是在正式 main 上留下未说明的失败。

integration-lab/heading.txt · text
Title: Small Steps
integration-lab/footer.txt · text
Footer: Local exercise
integration-lab/integration.test.mjs · javascript
import test from 'node:test';
import assert from 'node:assert/strict';
import { readFileSync } from 'node:fs';

const read = name => readFileSync(new URL(name, import.meta.url), 'utf8').trim();
test('heading includes the practice label', () => {
  assert.equal(read('heading.txt'), 'Title: Small Steps Lab');
});
test('footer identifies practice-only material', () => {
  assert.equal(read('footer.txt'), 'Footer: Practice only');
});
原目录：记录两项预期失败，再保存练习基准 · sh
node --test integration.test.mjs
git add -- heading.txt footer.txt integration.test.mjs
git commit -m "Add integration exercise and acceptance cases"
git status --short

步骤 2：分配两份互不覆写的交付

仍在 integration-lab：三个 checkout 都从 main 基准建立 · sh
git worktree add -b codex/heading ../integration-heading main
git worktree add -b codex/footer ../integration-footer main
git worktree add -b codex/integration ../integration-review main
git worktree list

A 只能改 integration-heading/heading.txt 为 Title: Small Steps Lab；B 只能改 integration-footer/footer.txt 为 Footer: Practice only。你可以手动完成这两个明确编辑，或在支援子代理的 Codex 主任务中明确委派两位工作者，分别提供完整路径、分支、唯一可写档案与回报格式。本篇参考验证使用手动等价编辑，不冒充已启动两个模型。

选用的主任务提示词：先替换两个完整路径 · text
Use two subagents with separate checkouts. Do not create more agents.
Agent A owns only <ABSOLUTE_HEADING_CHECKOUT>/heading.txt on codex/heading.
Set that file to 'Title: Small Steps Lab' with a final newline.
Agent B owns only <ABSOLUTE_FOOTER_CHECKOUT>/footer.txt on codex/footer.
Set that file to 'Footer: Practice only' with a final newline.
Neither agent may edit tests, merge, push, deploy or touch the other checkout.
Return the actual file diff and blockers. Leave staging and integration to the parent.
Wait for both agents before reviewing their results.
工作可写入档案此时测试预期
A 标题heading.txt标题通过、页尾尚未通过
B 页尾footer.txt页尾通过、标题尚未通过
整合者确认后的组合分支合并两份后两项通过

任何人若改了 integration.test.mjs，先查看原因与差异，不让工作者把验收目标改低。

原目录：逐一检查 diff；两次各一过一败为预期 · sh
git -C ../integration-heading diff -- heading.txt
git -C ../integration-footer diff -- footer.txt
node --test ../integration-heading/integration.test.mjs
node --test ../integration-footer/integration.test.mjs

步骤 3：保存后依序整合

等两份交付都停止修改后，查看完整 status，确认只改指定档案，再用下列命令提交。若已有其他人或工作者提交，先核对提交与 diff，不再重复提交。记录两条分支的 SHA，让整合对象具体；正式协作时若分支仍在变动，应使用已核对的提交或请持有人先停止写入，不在不断变更的目标上验收。

原目录：保存两份已核对交付 · sh
git -C ../integration-heading add -- heading.txt
git -C ../integration-heading commit -m "Label the practice heading"
git -C ../integration-footer add -- footer.txt
git -C ../integration-footer commit -m "Label the practice footer"
git rev-parse codex/heading codex/footer
原目录：依序合到检查分支并验收 · sh
git -C ../integration-review status --short
git -C ../integration-review merge --no-ff codex/heading -m "Integrate practice heading"
git -C ../integration-review merge --no-ff codex/footer -m "Integrate practice footer"
node --test ../integration-review/integration.test.mjs
git -C ../integration-review diff main...HEAD -- heading.txt footer.txt

预期整合目录两项通过，diff 同时包含标题与页尾的新值，而原 integration-lab 的 main 仍是初始文字。若第一个 merge 已冲突，先停止，不执行第二个；不能用某条分支自己的绿灯代替组合验收。这里的 --no-ff 用于让教材清楚保留两次整合纪录，真实储存库的合并策略仍依其规则决定。

原目录：记下已通过的整合 SHA · sh
git -C ../integration-review rev-parse HEAD

将这个完整 SHA 和两项通过结果放在同一笔纪录。完成下一步冲突与 abort 后，从原目录再执行同一命令，结果必须与此刻相同，并且 status 干净、两项仍通过；三者一起核对才能确认回到原状。不要把标题分支或 main 的 SHA 误填为整合 SHA。

步骤 4：刻意制造冲突并中止

原目录：建立另一个只供冲突练习的副本 · sh
git worktree add -b codex/conflict ../integration-conflict main

在 integration-conflict/heading.txt 把初始文字改成 Title: Another direction，保存并只提交该档。它从旧 main 起步，也改同一行，因此与整合分支的标题方向相冲突。先确认 integration-review 的 status 没有未提交修改、两项测试都通过，再尝试合入冲突分支。这个前提让 --abort 可以回到开始合并前的清楚状态，不拿含未保存工作内容的目录做演练。

原目录：预期 merge 非零且 heading.txt 显示冲突 · sh
git -C ../integration-conflict add -- heading.txt
git -C ../integration-conflict commit -m "Create a conflicting practice heading"
git -C ../integration-review merge --no-ff codex/conflict -m "Attempt conflicting integration"
git -C ../integration-review status --short

查看冲突档会看到两种标题与 Git 标记。这次不选任一方，而是保存错误和 status，执行 merge --abort。中止后再跑测试，预期恢复先前两项通过、status 干净。若工作目录在合并前本来就有修改，abort 不保证能重建所有未提交状态；因此不要省略前一步的检查。真正要解冲突时逐段决定保留行为，再重跑测试，不能一律取 ours 或 theirs。

有合并冲突时：中止并验证恢复 · sh
git -C ../integration-review merge --abort
node --test ../integration-review/integration.test.mjs
git -C ../integration-review status --short

收尾、常见问题与交付

测试找不到文字档时，确认三个档案都在同一份 checkout；此测试依自己的档案 URL 读资料，因此从原目录执行也不会误读另一份文字。status 显示未知修改时先问清来源；分支不存在时回看 worktree 建立与提交纪录；合并成功但验收失败时查组合 diff，不让工作者擅自改验收条件。不要把需要先产出共同介面的工作硬拆成彼此不知道规格的两个写入任务。

完成后停止练习工作者并关闭副本视窗，从原 integration-lab 核对 worktree list 的完整路径与四份副本的 clean status。只有本篇新增、成果已提交且未在使用的副本才依序移除；任何拒绝都先检查，不加 force。以下保留原库及 codex/integration 分支，所以之后仍能用 git show 查到组合成果。没有合并到正式 main，也没有开 PR。

核对四个完整目标与 clean 状态后：清理本篇副本 · sh
git worktree list
git worktree remove ../integration-heading
git worktree remove ../integration-footer
git worktree remove ../integration-review
git worktree remove ../integration-conflict
git show codex/integration:heading.txt
git show codex/integration:footer.txt

交付纪录包含两个输入 SHA、合并顺序、整合 SHA、两项测试结果、一次冲突与 abort 后的结果，以及保留原 main 的确认。参考 Git／Node 检查不等于 Codex 模型真的分工，也不等于网站已完成整页验收；未操作平台依官方文件查证。接续，将程式与画面验证补齐后，才准备你的正式专案交付。

原创流程示意图，非产品界面截图。
原创流程示意图，非产品界面截图。 · 图片：Mokaair (© Mokaair)
阅读完整文字说明

Three numbered stages: identify the starting point, perform the exercise, and verify the result. Original illustration, not a product screenshot.

回总目录

同主题延伸阅读

  • 生活分享

    Codex 学习中心：完整教程目录

    从安装、第一个任务到 MD 规则与进阶集成，规划 60 篇 Codex 教程、十个单元。按程度、平台、需求或命令搜索下一篇；尚未公开的教程会标示状态，方便安排学习路线。

  • 生活分享

    Worktree 与多任务隔离

    Worktree 让同一个 Git 程式库有不同的工作目录，各自承接不同分支。它适合让两项工作分开改档，但资料库、连接埠与外部服务仍可能共用，不能把档案隔离当成所有资源隔离。

  • 生活分享

    实战：制作小网站

    从 brief.md 规划并制作 Small Steps 待办网站，完成新增、完成、删除、筛选与本机资料保存。将 HTML、CSS、资料函式、画面事件与测试分开，以 Node 测试和浏览器操作验收，并留下可重新启动与还原的交接纪录。

  • 生活分享

    用量与效率：减少重工

    记录任务条件、模型选项、时间与成果，找出能减少无效重试和过多上下文的调整。

引用本文的文章

最新旅游情报攻略

资料来源

生活分享