ライフスタイル

並行作業の統合と確認

ファイルとインターフェースの契約に沿って変更を統合し、衝突と全体動作を確認します。

読了目安 20 分 · 操作 30 分

独自の手順図です。製品画面の画像ではありません。
画像：Mokaair (© Mokaair)
総目次へ：Codex 学習ガイド：全記事の目次

上級 · Desktop / CLI / VS Code / JetBrains

この記事の目次
  1. 目標と準備
  2. 手順1：共通の検証教材を準備
  3. 手順2：上書きしない二交付へ分担
  4. 手順3：保存して順序統合
  5. 手順4：意図的競合と中止
  6. 片付け・問題・交付

目標と準備

この段落の教材・資料: ·

並行で短縮できても統合には順序があります。二人の完了は各ブランチの完了にすぎず、両方の変更を使う同一画面は組合せ版で確認が必要です。今回は見出しとフッターのファイルで成果物を表し、全サイトのテストとは呼びません。後で実際のビルドと画面確認に適用します。

手順1：共通の検証教材を準備

新 integration-lab を作って端末を開きます。全 OS で下記 Git・Node は共通です。経路と同階層四名称の不存在を確認し、既存なら一式を未使用名へ揃えて変更します。元作業を上書きしません。

新しい integration-lab の端末：このリポジトリだけ設定 · sh
git init -b main
git config user.name "Codex Learner"
git config user.email "learner@example.test"

下記三ファイルを作り、見出しとフッターの初期値に末尾改行を残します。テストは未実装の新要件二つを表すため、基準は意図した0件成功・2件失敗です。リモートなしの独立教材であり、本番の 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：三コピーとも 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 は見出し側コピーの一ファイルだけ、B はフッター側コピーの一ファイルだけを指定値へ変えます。手動で行うか、対応する 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フッター成功・見出し未完
統合者確認済みの組合せ両方の統合後に二項目成功

テスト変更があれば理由と差分を確認し、要件を弱めさせません。

元端末：各差分と一成功・一失敗を確認 · 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：保存して順序統合

両者の書込み終了後、全状態と対象一ファイルだけを確認してコミットします。既コミットなら差分を確認し二重コミットしません。両 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

統合先は二項目成功、差分は両方の新しい値、元の main は初期値のままです。最初の merge が競合したら二回目へ進みません。個別の成功で組合せ確認を代用しません。教材では履歴を示すため --no-ff を使い、実際のリポジトリではその方針に従います。

元フォルダー：成功した統合 SHA を記録 · sh
git -C ../integration-review rev-parse HEAD

この完全 SHA と二項目の成功を同じ記録に残します。次の競合と abort 後、元フォルダーから同じコマンドで同じ SHA、変更なしの状態、二項目の成功を確認します。見出し側ブランチや main の SHA を統合 SHA と取り違えません。

手順4：意図的競合と中止

元端末：競合練習専用のコピー作成 · sh
git worktree add -b codex/conflict ../integration-conflict main

競合側コピーの見出しだけを Title: Another direction にしてコミットします。旧 main から同じ行を違う値へ変えるため統合先と競合します。確認ディレクトリが変更なしで二項目のテストに成功することを確認してから試し、未保存作業ではなく明確な開始状態へ abort で戻します。

元の端末：0以外の merge 終了コードと見出しの競合を確認 · 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 識別マーカーを見て、今回は選択せずエラー・状態を残して abort します。二成功と未変更へ戻るはずです。開始前に未コミットがあると完全復元を保証できないので確認を省略しません。実解消では部分ごとに動作を選び、全て ours/theirs にしません。

競合中：中止と復旧確認 · sh
git -C ../integration-review merge --abort
node --test ../integration-review/integration.test.mjs
git -C ../integration-review status --short

片付け・問題・交付

教材はテスト自身の URL を基準に読むため、ファイルがなければ同じコピーに三つ揃っているか確認します。不明な変更は出所、ブランチ不在は作成・コミット、統合後の失敗は組合せ差分を調べます。テストを弱めたり、共通インターフェースが未定の依存作業を無理に独立分担したりしません。

作業者とコピーのウィンドウを閉じ、元から四つのパスと clean 状態を確認します。追加済み、コミット済み、未使用のものだけ削除し、拒否されても force で回避しません。元のリポジトリと統合ブランチを残すため、後で成果を読めます。本番 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 の参考試験はモデル分担や全画面検証ではなく、未操作 OS は公式確認とします。で画面確認へ進みます。

独自の手順図です。製品画面の画像ではありません。
独自の手順図です。製品画面の画像ではありません。 · 画像：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 レッスン・十単元を予定しています。習熟度、環境、目的、コマンドで次の記事を探せます。未公開の記事には状態を表示します。

  • ライフスタイル

    Worktree とタスクの分離

    Worktree は一つの Git リポジトリに別ブランチの作業場所を作ります。ファイルは分かれても DB、ポート、外部サービスは共有される場合があります。

  • ライフスタイル

    実践：小さな Web サイトを作る

    brief.md から Small Steps のタスクサイトを計画・制作し、追加、完了、削除、絞り込み、ローカル保存を実装します。HTML、CSS、データ関数、画面イベント、テストを分け、Node とブラウザーで検証して再起動・復元の手順を残します。

  • ライフスタイル

    使用量と効率：やり直しを減らす

    条件、モデル設定、時間、成果を記録し、不要な再試行と過剰な文脈を減らします。

この記事を引用している記事

最新の旅の情報・ガイド

出典

ライフスタイル