個人開発でGit-Flowは過剰でしょうか？ 私もそう思っていました。しかし本番稼働中のシステムに新機能を追加し続ける運用では、ブランチ管理の欠如が直接的な事故につながりました。
本記事では、1人開発でGit-Flowを導入し、Claude Codeと組み合わせて運用している実践例を記録します。特に「mainへの直接コミット禁止」がどれだけの事故を防いだかを説明します。
なぜGit-Flowが必要になったか
事故：mainブランチへの直接コミットで本番停止
開発初期はmainブランチ1本で運用していました。ある日、Claude Codeで機能改善をしてコミットし、本番環境でgit pullしました。
1$ git pull2$ # 本番のlaunchdジョブが次回実行時に新しいコードを読み込む3$ # → ImportError で全ジョブ停止原因は、モジュール名の変更を全ファイルに反映していなかったことです。Dev環境ではテスト対象のファイルだけが読み込まれるため問題ありませんでしたが、本番ではlaunchdジョブ経由で別のファイルも読み込まれ、そこでImportErrorが発生しました。
この事故で「mainは本番と直結しているのだから、直接コミットしてはいけない」と学びました。
ブランチ構成
1main2 │ ← 本番環境（launchdが実行するコード）3 │4 ├── pre5 │ ← Pre環境（Dry-Run検証）6 │7 └── develop8 │ ← 開発統合・テスト9 │10 ├── feature/new-11-trailing-stop11 ├── feature/rng-a1-regime-detection12 └── feature/us-b1-vix-tail-insurance| ブランチ | 用途 | マージ先 |
|---|---|---|
main | 本番環境 | — |
pre | Pre環境Dry-Run | main（Go判定後） |
develop | 開発統合 | main（リリース時） |
feature/* | 個別施策 | develop |
hotfix/* | 緊急修正 | main + develop |
運用スクリプト
ブランチ操作をスクリプト化して、ミスを防ぎます。
1# 新機能開発の開始2./scripts/git-new-feature.sh trailing-stop3# → develop から feature/trailing-stop を作成4
5# リリース6./scripts/git-release.sh v3.8.317# → develop を main へマージ + タグ作成8
9# 緊急修正10./scripts/git-new-hotfix.sh fix-import-error11# → main から hotfix/fix-import-error を作成12# → 修正後、main と develop の両方にマージ手動でgit checkoutやgit mergeを打たずに済みます。タイプミスやマージ先の間違いを防止できます。
Claude Codeとの連携
CLAUDE.mdにブランチルールを記載
1## Git-Flow ブランチ戦略2- main への直接コミット禁止（緊急 hotfix 除く）3- 新機能開発: ./scripts/git-new-feature.sh <name> で feature/* を作成4- リリース: ./scripts/git-release.sh <version>5- 緊急修正: ./scripts/git-new-hotfix.sh <name>これにより、Claude Codeに「コミットしてください」と言ったとき、mainブランチにいる場合は自動的に警告します。
AIがマージ先を間違える問題の対策
Claude Codeに「PRを作成してください」と言うと、デフォルトではmainに向けてPRを作ろうとすることがあります。
1# CLAUDE.mdに追記2- feature/* ブランチの PR は develop に向けて作成すること3- main への直接 PR は hotfix/* のみ許可CLAUDE.mdの即時同期問題
CLAUDE.mdは全ブランチで参照されます。feature/*ブランチでCLAUDE.mdを更新した場合、mainやdevelopにも反映しないと、別のセッションで古いルールが適用されてしまいます。
1# CLAUDE.md改訂時の即時同期ルール2CLAUDE.md / .wbs/CURRENT.md を改訂した場合、3main・pre・develop の全ブランチに反映すること。4
5git checkout main && git checkout feature/xxx -- CLAUDE.md && git commit6git checkout develop && git checkout feature/xxx -- CLAUDE.md && git commithotfixフロー：本番障害の緊急修正
実際のhotfix事例
2026年3月の深夜、Slack通知で本番障害を検知しました。特定のAPIレスポンスのフォーマットが変わり、パースエラーが発生していました。
1# 1. hotfixブランチ作成（mainから分岐）2./scripts/git-new-hotfix.sh fix-api-response-format3
4# 2. Claude Codeで修正5# 「APIレスポンスのフォーマット変更に対応してください。6# 変更前: {"data": {...}}7# 変更後: {"data": [{...}]}8# エラーログ: [貼り付け]」9
10# 3. テスト実行11pytest tests/ -v12
13# 4. mainにマージ（直接）14git checkout main && git merge hotfix/fix-api-response-format15
5 collapsed lines
16# 5. developにも反映17git checkout develop && git merge hotfix/fix-api-response-format18
19# 6. 本番に反映20ssh production "cd data-processing && git pull"hotfixはmainから分岐し、mainとdevelopの両方にマージします。developへの反映を忘れると、次回リリース時にhotfixの修正が上書きされて再発します。
PRテンプレートの標準化
Claude Codeが作成するPRには、以下のテンプレートを使います。
1## Summary2- [1-3行の変更概要]3
4## Test plan5- [ ] ユニットテスト PASS6- [ ] 回帰テスト PASS（全エンジン合計 7,000+テスト）7- [ ] mypy型チェック PASS8- [ ] Dry-Run実行確認（Pre環境で）テスト件数の明記
PRに「4,150件 PASS」と具体的な数字を書くことで、レビュー時にテストの網羅性が一目でわかります。数字がないと「テストは通った」が信頼できません。
バージョニング
セマンティックバージョニング（SemVer）を採用しています。
1v3.8.312│ │ │3│ │ └─ パッチ: バグ修正・小改善4│ └─── マイナー: 新機能追加（後方互換あり）5└───── メジャー: 破壊的変更リリーススクリプトが自動的にタグを作成します。
1./scripts/git-release.sh v3.8.322# → develop を main にマージ3# → git tag v3.8.32 を作成4# → push学んだこと
1. 個人開発でもmainへの直接コミット禁止は効果がある
「自分しかいないのだからmainに直接コミットしても問題ない」は間違いです。mainは本番と直結しているため、テストされていないコードが入ると即座に事故になります。
2. ブランチ操作はスクリプト化する
git checkout、git merge、git tagを手打ちすると、ブランチ名やマージ先の間違いが起きます。スクリプト化すれば、操作ミスがゼロになります。
3. CLAUDE.mdの全ブランチ同期は忘れやすい
feature/*でCLAUDE.mdを更新しても、main/develop/preへの反映を忘れがちです。チェックリストに「CLAUDE.md同期」を入れる必要があります。
4. hotfixはdevelopにも反映する
hotfixをmainだけにマージすると、次回リリース時にdevelopの古いコードで上書きされます。hotfixは常にmain + developの両方にマージします。
まとめ
個人開発のGit-Flowで重要なのは以下の3点です。
- mainへの直接コミット禁止: 本番 = mainなので、develop経由でのみ変更を入れます
- 操作のスクリプト化: git-new-feature.sh / git-release.sh / git-new-hotfix.sh でミスを排除します
- CLAUDE.mdの全ブランチ同期: AIへの指示書はどのブランチでも最新でなければなりません
「1人だからGit-Flowは不要」ではなく、「1人だからこそミスを防ぐ仕組みが必要」です。