生活分享

平行工作後的整合與驗收

依檔案與介面契約整合獨立修改，處理衝突，再驗證合併後的整體行為。

閱讀時間約 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 測試和瀏覽器操作驗收，並留下可重新啟動與還原的交接紀錄。

  • 生活分享

    用量與效率：減少重工

    記錄任務條件、模型選項、時間與成果，找出能減少無效重試和過多上下文的調整。

引用本文的文章

最新旅遊情報攻略

資料來源

生活分享