朝、case100 の作業を再開しようとして memo/2026-05-03/ を開いたら、昨日まで書いていたメモが消えていた。一瞬手が止まって背筋が冷えたが、git status を叩いたら原因はすぐに割れた。メインブランチで作業しているつもりが、実際には fix/e2e-stabilize-wait というブランチに乗ったまま昨日の作業を終えていて、main に戻ってきたらそのブランチで作ったファイルが視界から消えていた、というだけの話だった。
ファイルは消えていない。git の中で別のブランチに居る。それを思い出すまでに10秒くらい固まった。
今日はこの「ブランチ跨ぎで起きた錯覚 → 状態整理 → PR #16 を main にマージするまで」のワークフローを、Claude Code に手順を組ませて順次実行した記録を残す。
状況の整理
朝イチで git status と git log --oneline --all --graph を叩いて、頭の中の地図を描き直した。
- 現在
mainに居る fix/e2e-stabilize-waitが main より 11コミット先行している(case100 関連の作業はすべてこちら側)- 一方で main にも未コミットの変更がある(並行で開いた別セッションで触ったファイル群)
- 「memoが消えた」のは、
fix/e2e-stabilize-waitで作っていたmemo/2026-05-03/がまだ main に来ていないだけ
ここまで見えれば手順は組める。データ消失の心配は基本ない。Git は未コミット変更を上書きしそうな時は警告でブロックしてくれる。
ワークフロー(案A:順次実行)
Claude Code に「次の手順で進めて」と渡したのは以下の流れ。
# 1. main の未コミット変更を退避(untracked も含めるため -u フラグ)
git stash push -u -m "main work in progress before switching"
# 2. main を最新化
git pull --ff-only origin main
# 3. fix/e2e-stabilize-wait に切り替え、main を取り込む
git checkout fix/e2e-stabilize-wait
git merge main
# 4. push
git push origin fix/e2e-stabilize-wait
# 5. PR 作成(本文素案を提示してから実行)
gh pr create --title "..." --body "..."
# 6. CI 緑確認 → ユーザーが GitHub UI で Squash & Merge
# (ここで一旦止める)
# 7. main に戻して fetch、stash 復元
git checkout main
git pull --ff-only origin main
git stash pop
# 8. ローカルブランチを削除
git branch -d fix/e2e-stabilize-wait
ポイントは 5番と6番の境界で必ず止めること。リモートに見える操作(push、PR作成、マージ)は、各境界で手を止めてユーザーが目視確認する運用にしている。AI が「勢いでマージまで」やってしまうと取り返しがつかない。
試行錯誤と気づき
1. git checkout が権限プロンプトで弾かれた
3番の git checkout fix/e2e-stabilize-wait で Claude Code が拒否された。プロジェクトの設定で許可されていないコマンドだったらしい。リトライしても同じところで止まる。
ここはユーザー側で !git checkout fix/e2e-stabilize-wait を手で打ち、Claude Code に作業を返した。権限で詰まったらユーザー手動実行(!command 形式)でカバーできる、という運用は覚えておいて損がない。Claude Code 側に全部やらせようとして無理に権限を緩めるより、人間がワンショットで打つ方が早い場面は多い。
2. stash 復元で「差分が消えた」ように見えた
一番焦ったのが7番の git stash pop。
main に戻って stash を復元したら、ほとんどのファイルで差分が出てこなかった。「あれ、stash の中身どこ行った?」と画面を凝視した。
種を明かすと、stash に入れていた変更の大半は PR #16 のコミットにすでに含まれていた。並行セッションで触っていたファイルが、fix/e2e-stabilize-wait 側でも同じように編集されていて、Squash & Merge で main に取り込まれた瞬間に「stash の中身 = main の現在の状態」になり、差分がゼロになっていた。
つまり差分消失は no-op、これは正しい挙動。同期が完了している証拠だった。git は淡々と「同じ内容なので適用するものがありません」と言っているだけ。
3. memo が「消えた」のはマージ直後のキャッシュ
そもそもの発端だった「memoが消えた」も、PR #16 のマージ直後にエクスプローラーが古い状態を表示していただけだった。git の状態を見たら、memo/2026-05-03/ のファイル群はすべて main に入っていた。
ファイルが見えない時はまずエクスプローラーを信じず、git status と git log -- memo/2026-05-03/ を叩く。これに尽きる。
学んだこと
- ブランチを跨いで並行作業していると、目に見えるファイルが切り替わる。「消えた」と感じたら、まず
git branchで今どこに居るかを確認する git stashは untracked を含めるなら-uフラグを忘れない。これを忘れると新規ファイルだけ取り残されてもう一度焦るmainと作業ブランチを並走させるときは、こまめにgit statusで位置を取る。30分に1回見るだけでも錯覚は消える- Claude Code が権限プロンプトで止まったら、ユーザーが
!commandで手動実行して作業を返す運用が回る。AI に全権を渡そうとしない - stash 復元で差分が消えても、それは同期完了の合図のことが多い。慌てて
git stash dropする前にgit logを見る - リモートに見える操作(push、PR作成、マージ)は各境界で必ず手を止める。順次実行と自動実行は別物
結果
PR #16 は無事 Squash & Merge で main に入り、fix/e2e-stabilize-wait ローカルブランチも削除した。main は最新化され、case100 関連の11コミット分の作業が main に取り込まれた状態になった。
朝の「memoが消えた」事案は10秒で錯覚と判明し、そこから30分でPRマージと後片付けまで終わった。Claude Code に手順を組ませて段階ごとに止めながら進める運用は、こういう「複数ブランチを跨いだ整理作業」と相性がいい。次に同じ場面が来たら、もう一度この記事を見返す。