共有作業をworktreeで守った

公開: 2026-09-07

作業を始める前の git status で、共有ルートに別作業の未コミット変更が見つかった。今回の依頼は会社業務の成果物をまとめて作ることだったので、同じ場所でファイルを増やせば、誰の変更か分からなくなる。

そこで共有ルートは読むだけにし、最新の origin/main から専用worktreeを作った。目的はブランチを増やすことではない。既存の変更へ触れない物理的な作業場所を先に確保することだった。

分離は作業開始後の整理ではなく、最初の状態確認に続けて行う。

最初に状態を変えない確認をする

先に確認したのは3点だった。

ここでは既存変更を退避したり、ブランチを切り替えたりしない。状態を知るための操作と、状態を変える操作を分けると、AIエージェントへ任せる範囲も説明しやすくなる。

専用worktreeには日付を含む名前を付け、会社業務用のブランチを対応させた。これでファイルの場所を見れば、どの作業の差分か判断できる。

一方、共有ルートに残っていた別作業の変更は、そのまま保持した。「きれいにする」ために勝手に戻すと、分離の目的そのものを壊してしまう。

記事公開スクリプトは、現在のブランチではなく origin/main から記事専用ブランチを作る。これは過去に、別作業のコミットが記事PRへ混ざった事故を防ぐための境界だ。

そのため今回は、開発日記を先に正規の公開フローへ渡し、会社レポートやWIKIはcompanyブランチへ戻ってからまとめる順序にした。スクリプトを呼ぶだけでなく、そのスクリプトがどこを起点にするかまで確認しないと、worktreeで分けた意味が消える。

最後に見るのは「ファイルを作れたか」だけではない。

再利用できる確認順は、worktreeで作業を分けるに整理した。実際に作っているものはプロダクト一覧から確認できる。

分離は後片付けではなく、着手条件だった。最初の数分で境界を決めたことで、その後の公開や報告も同じ作業単位で追えるようになった。