読み込み中...
この記事は、ひとりで作るSaaS - 設計・実装・運用の記録 Advent Calendar 2025 の5日目の記事です。
昨日の記事では「個人開発のドキュメント戦略」について書きました。今日は、個人開発におけるGitブランチ戦略について書きます。
チーム開発では、Git-flowやGitHub Flowなど確立されたブランチ戦略があります。しかし、個人開発では状況が異なります。
個人開発の特徴:
一方で、以下の課題もあります。
これらを踏まえて、私が個人開発しているMemoreruでは以下のブランチ戦略を採用しています。
Git Worktreeを使うと、複数のディレクトリでそれぞれ別のブランチを同時に開けます。通常のブランチ切り替えと違い、ローカルに物理的なフォルダが分かれるため、それぞれの場所で別々のClaude Codeセッションを起動できます。
一番の理由は、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はその基盤として非常に有効です。
その他のメリット:
並列作業が必要になったときに、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-refactorfeature → develop → main（本番）→ Vercel自動デプロイ
my-project（develop）で作業# ✅ 機能単位でコミット
git commit -m "feat: ユーザープロフィール編集機能を追加"
git commit -m "fix: ログイン時のエラーハンドリングを修正"
# ❌ 複数機能を一括コミット
git commit -m "いろいろ修正"ポイント:
# ❌ mainへの直接push
git push origin main # 禁止！
# ✅ 必ずdevelop → PR → mainの流れ
git push origin develop
# → GitHub上でPRを作成mainへの直接pushは、本番環境を壊すリスクがあるため禁止しています。
Claude Codeで開発する際は、以下のルールをCLAUDE.mdに明記しています。
## Git運用
### ブランチ戦略（Git Worktree）
- **日常の開発**: `~/my-project` (develop) で作業
- **並列作業**: featureブランチをWorktreeで作成
- **本番デプロイ**: GitHub上でPR作成 → merge → Vercel自動デプロイ
### コミット・プッシュルール
- **機能単位コミット**: 複数機能の一括変更禁止
- **mainへの直接push厳禁**: 必ずdevelop → PR → mainの流れ
- **動作確認必須**: コミット前に画面で動作確認
- **ユーザー確認後のコミット実行**: 勝手にコミットしない特に重要なのは「勝手にコミットしない」というルールです。AIが良かれと思って自動コミットすると、意図しない変更が入る可能性があります。コミットは必ず人間が確認してから実行します。
Vercelは、GitHubリポジトリと連携して自動デプロイを行います。
| ブランチ | デプロイ先 | URL |
|---|---|---|
| main | Production | example.com |
| develop | Preview | develop-xxx.vercel.app |
PRを作成すると、Preview環境に自動デプロイされます。本番反映前に確認できるので便利です。
ドキュメントだけの更新でデプロイを走らせたくない場合は、コミットメッセージに[skip ci]を含めます。
git commit -m "docs: READMEを更新 [skip ci]".github/pull_request_template.mdを用意しておくと、PRの品質が安定します。
## 概要
<!-- 何を変更したか -->
## 変更内容
-
## テスト確認
- [ ] ローカルで動作確認済み
- [ ] Preview環境で確認済み
## 備考GitHub上でmainブランチを保護すると、直接pushを防げます。
Settings → Branches → Branch protection rules:
個人開発でも設定しておくと、うっかりミスを防げます。
現在のWorktreeを確認するには以下のコマンドを使います。
git worktree list
# ~/my-project abcd123 [develop]
# ~/my-project-feature1 efgh456 [feature/ui-refactor]不要になったWorktreeはgit worktree removeで削除しましょう。
Memoreruでの実践から得た学びをまとめます。
うまくいっていること:
注意が必要なこと:
個人開発だからといってGit運用を適当にすると、後で困ることになります。最低限のルールを決めておくことをおすすめします。
明日は「Supabaseでスキーマ設計：テーブル分割と正規化の実践」について解説します。
シリーズの他の記事
コメント