worktreeで分ける

共有リポジトリでAIエージェントを並行稼働するとき、最初の仕事はコード変更ではなく境界の確認になる。 未コミット変更がある共有ルートでブランチを切り替えると、別作業の差分を持ったまま新しい仕事を始めてしまう。

先に読むだけの確認をする

確認する項目は次の3つで足りる。

1. git status --short --branch で共有ルートの変更を把握する
2. git worktree list --porcelain で利用中の作業場所とブランチを把握する
3. git fetch origin --prune 後の origin/main を新規作業の起点にする

この段階で共有ルートの変更を戻したり、一時退避したりしない。誰の変更か分からないものは、所有者の作業として保持する。

専用領域を一対一で作る

作業名が分かるディレクトリとブランチを一対一にする。

git worktree add -b content/company-YYYY-MM-DD ../codese-company-YYYY-MM-DD origin/main

作成後は、そのworktreeを作業ディレクトリにして変更する。共有ルートから相対パスで別領域のファイルを書き換える運用は、境界を見えにくくするので避ける。

公開処理の起点を確認する

公開スクリプトが現在のHEADを使うとは限らない。実際に今回確認した publish-blog.sh は、過去のコミット混入事故を防ぐため、記事専用ブランチを origin/main から作る。

したがって、会社レポートを先に未コミットで積んだ状態から公開処理を呼ぶと、ブランチ切り替えに失敗するか、対象ファイルが起点側に存在しなくなる。次のどちらかに順序を固定する。

• 記事とアイキャッチだけを先に正規公開し、元の作業ブランチへ戻って残りを作る
• 全成果物のPRを先に完了し、公開権限を得てからデプロイと公開確認を行う

外部公開の承認が無い場合は、後者の途中、つまりローカルコミットで止める。回避経路でデプロイしない。

終了時に4点を照合する

1. 共有ルートの既存差分が開始時から変わっていない
2. 新規成果物が専用ブランチだけに属している
3. 記事が参照する画像も同じ差分に含まれている
4. 未実施のPR、デプロイ、外部投稿を完了扱いしていない

実際にこの手順を適用した経緯は、共有作業をworktreeで守ったに残した。作っているプロダクトはプロダクト一覧から確認できる。