この記事は、ひとりで作るSaaS - 設計・実装・運用の記録 Advent Calendar 2025 の5日目の記事です。
昨日の記事では「個人開発のドキュメント戦略」について書きました。今日は、個人開発におけるGitブランチ戦略について書きます。
🎯 個人開発のGit運用で考えるべきこと
チーム開発では、Git-flowやGitHub Flowなど確立されたブランチ戦略があります。しかし、個人開発では状況が異なります。
個人開発の特徴:
- 開発者は自分一人（コンフリクトが起きにくい）
- レビュアーがいない（セルフレビューが基本）
- 素早く改善サイクルを回したい（手続きは最小限にしたい）
一方で、以下の課題もあります。
- 本番環境を壊したくない
- 変更履歴を追いやすくしたい
- AIエージェント（Claude Code）と協働する際のルールが必要
これらを踏まえて、私が個人開発しているMemoreruでは以下のブランチ戦略を採用しています。
📂 Git Worktreeで並列開発
Git Worktreeを使うと、複数のディレクトリでそれぞれ別のブランチを同時に開けます。通常のブランチ切り替えと違い、ローカルに物理的なフォルダが分かれるため、それぞれの場所で別々のClaude Codeセッションを起動できます。
なぜGit Worktreeか
一番の理由は、Claude Codeで並列開発ができるからです。
たとえば「検索機能のリファクタリング」と「決済機能の実装」という2つの大きなタスクがあるとします。それぞれ別のWorktreeを作成し、別々のClaude Codeセッションで進めます。
~/my-project/ # develop ブランチ（メインの作業場所）
~/my-project-search/ # feature/search-refactor（検索機能）
~/my-project-payment/ # feature/payment（決済機能）
ポイントは、セッションごとに会話の文脈が分かれることです。
検索機能のセッションでは検索に関する議論が蓄積され、決済機能のセッションでは決済に関する議論が蓄積されます。文脈が混ざらないので、それぞれのタスクに集中した会話ができます。
セッション1（検索機能）: 「このクエリの最適化について...」
セッション2（決済機能）: 「Stripeのwebhook処理について...」
→ 互いに干渉せず、それぞれの文脈で深い議論ができる
個人開発でも、AIエージェントを活用すれば「擬似的なチーム開発」が可能になります。Git Worktreeはその基盤として非常に有効です。
その他のメリット:
- ブランチ切り替えのたびにサーバー再起動が不要
- stash → checkout → pop の手間がない
- 「今どのブランチにいるか」を常に意識する必要がない
セットアップ方法
並列作業が必要になったときに、featureブランチ用のWorktreeを追加します。
# メインのリポジトリ（develop）
cd ~/my-project
git branch # developにいることを確認
# featureブランチを作成してWorktreeを追加
git worktree add ../my-project-feature1 -b feature/ui-refactor
これで~/my-project-feature1ディレクトリが作成され、feature/ui-refactorブランチがチェックアウトされます。
作業完了後のクリーンアップ
featureブランチをdevelopにマージしたら、Worktreeを削除します。
# Worktreeを削除
git worktree remove ../my-project-feature1
# ブランチも削除（マージ済みなら）
git branch -d feature/ui-refactor
🔄 ブランチ運用ルール
基本の流れ
feature → develop → main（本番）→ Vercel自動デプロイ
-
日常の開発:
my-project（develop）で作業 - 並列作業: featureブランチをWorktreeで作成し、Claude Codeで並列開発
- マージ: feature → develop へPR、または直接マージ
- 本番デプロイ: develop → main へPR → Vercelが自動デプロイ
コミットルール
# ✅ 機能単位でコミット
git commit -m "feat: ユーザープロフィール編集機能を追加"
git commit -m "fix: ログイン時のエラーハンドリングを修正"
# ❌ 複数機能を一括コミット
git commit -m "いろいろ修正"
ポイント:
- 機能単位でコミット（複数機能の一括変更禁止）
- プレフィックスを使用（feat, fix, docs, refactor等）
- 動作確認してからコミット
やってはいけないこと
# ❌ mainへの直接push
git push origin main # 禁止！
# ✅ 必ずdevelop → PR → mainの流れ
git push origin develop
# → GitHub上でPRを作成
mainへの直接pushは、本番環境を壊すリスクがあるため禁止しています。
🤖 AIエージェントとの協働ルール
Claude Codeで開発する際は、以下のルールをCLAUDE.mdに明記しています。
## Git運用
### ブランチ戦略（Git Worktree）
- **日常の開発**: `~/my-project` (develop) で作業
- **並列作業**: featureブランチをWorktreeで作成
- **本番デプロイ**: GitHub上でPR作成 → merge → Vercel自動デプロイ
### コミット・プッシュルール
- **機能単位コミット**: 複数機能の一括変更禁止
- **mainへの直接push厳禁**: 必ずdevelop → PR → mainの流れ
- **動作確認必須**: コミット前に画面で動作確認
- **ユーザー確認後のコミット実行**: 勝手にコミットしない
特に重要なのは「勝手にコミットしない」というルールです。AIが良かれと思って自動コミットすると、意図しない変更が入る可能性があります。コミットは必ず人間が確認してから実行します。
📋 Vercelとの連携
Vercelは、GitHubリポジトリと連携して自動デプロイを行います。
ブランチとデプロイ環境の対応
| ブランチ | デプロイ先 | URL |
|---|---|---|
| main | Production | example.com |
| develop | Preview | develop-xxx.vercel.app |
PRを作成すると、Preview環境に自動デプロイされます。本番反映前に確認できるので便利です。
ドキュメント更新時のスキップ
ドキュメントだけの更新でデプロイを走らせたくない場合は、コミットメッセージに[skip ci]を含めます。
git commit -m "docs: READMEを更新 [skip ci]"
💡 実践Tips
Tip 1: プルリクエストのテンプレート
.github/pull_request_template.mdを用意しておくと、PRの品質が安定します。
## 概要
<!-- 何を変更したか -->
## 変更内容
-
## テスト確認
- [ ] ローカルで動作確認済み
- [ ] Preview環境で確認済み
## 備考
Tip 2: ブランチ保護ルール
GitHub上でmainブランチを保護すると、直接pushを防げます。
Settings → Branches → Branch protection rules:
- Require a pull request before merging
- Require status checks to pass before merging
個人開発でも設定しておくと、うっかりミスを防げます。
Tip 3: Worktreeの一覧確認
現在のWorktreeを確認するには以下のコマンドを使います。
git worktree list
# ~/my-project abcd123 [develop]
# ~/my-project-feature1 efgh456 [feature/ui-refactor]
不要になったWorktreeはgit worktree removeで削除しましょう。
✅ まとめ
Memoreruでの実践から得た学びをまとめます。
うまくいっていること:
- Git Worktreeでfeatureブランチを並列管理し、Claude Codeで擬似チーム開発
- develop → PR → mainの流れで本番を保護
- CLAUDE.mdでAIエージェントにルールを伝達
注意が必要なこと:
- 個人開発でも油断すると本番を壊す
- AIに任せきりにせず、コミットは人間が確認
- 使い終わったWorktreeは忘れずに削除
個人開発だからといってGit運用を適当にすると、後で困ることになります。最低限のルールを決めておくことをおすすめします。
明日は「Supabaseでスキーマ設計：テーブル分割と正規化の実践」について解説します。
シリーズの他の記事
- 12/4: 個人開発のドキュメント戦略：設計書・思考ログの使い分け
- 12/6: Supabaseでスキーマ設計：テーブル分割と正規化の実践