推奨ブランチ運用 — GitHub Flow と ailms の実例
学習目標
このレッスンを終えると、次のことができるようになります。
- GitHub Flow (シンプルなブランチ戦略) を 5 ステップで説明できる
- Git Flow との違いを理解し、選択基準を持てる
- ailms プロジェクトでの実際の運用ルールを参照できる
2 つの代表的なブランチ戦略
| 戦略 | 特徴 | 向いている |
|---|---|---|
| GitHub Flow | main + 短命 feature ブランチのみ。シンプル |
連続デリバリ・SaaS・小〜中規模チーム |
| Git Flow | main + develop + feature/* + release/* + hotfix/* の 5 種類 |
リリースバージョンが明確なパッケージ製品 |
ailms は GitHub Flow を採用。Web サービスは 1 日に何度もデプロイするので、Git Flow の重い手続きは不要。
GitHub Flow の 5 ステップ
flowchart TB
M1[main を最新化<br/>git pull origin main] --> B[branch を切る<br/>git switch -c feature/X]
B --> C[作業 + commit を重ねる]
C --> P[push して GitHub に出す<br/>git push -u origin feature/X]
P --> PR[Pull Request を作る]
PR --> R[レビュー + 必要なら修正]
R --> MG[main に merge<br/>GitHub Web UI で]
MG --> D[main をデプロイ]
D --> CL[ブランチ削除<br/>役目終了]
| ステップ | コマンド (CLI) | 補足 |
|---|---|---|
| 1. main を最新に | git switch main && git pull |
古い main から切ると後で痛む |
| 2. ブランチを切る | git switch -c feature/<目的> |
1 機能 = 1 ブランチ |
| 3. 作業 + commit | エディタ・AI で編集 → git commit |
意味ある単位で commit |
| 4. push | git push -u origin feature/<目的> |
-u で追跡設定 (初回のみ) |
| 5. PR → review → merge | GitHub Web UI で | レビューは別レッスンで |
「直接 main に push」を禁止する仕組み
GitHub の branch protection rule (ブランチ保護ルール) で main を保護する。
flowchart LR
P[git push origin main] --> G{GitHub branch<br/>protection check}
G -->|未保護| O[OK push 通る]
G -->|保護あり| B[REJECT<br/>PR を作ってください]
ailms では次の保護を有効化:
- ✅ Pull Request を経由しないと merge 不可
- ✅ 最低 1 名のレビュー承認が必要
- ✅ ステータスチェック (CI / テスト) 通過が必須
- ✅ 管理者も保護対象 (例外なし)
ailms の実運用ルール
CLAUDE.md から引用 (一部簡略):
- 破壊的操作 (rm -rf, push --force, 本番デプロイ等) は人間の承認後に実行
- `git push` も毎回人間の明示承認後に実行。前の承認は次の変更に引き継がない
- 無関係な差分をまとめて commit しない
- 同じ事故が 2 回起きたら、注意ではなくルール・テスト・スクリプトに昇格する
- `commit & push は AI が積極的に実行する` (CLAUDE.md フィードバックで確定。
人間承認が必要なのは Phase 0 結果と本番デプロイのみ)
注意: AI Agent への指示は 「やってはいけない」を文章 + Hook の二重防御。 ailms には
scripts/git-hooks/install.shでpre-commit/pre-pushフックが入っており、 破壊的パターンを機械的にブロックしている。
1 機能 = 1 ブランチ = 1 PR の原則
複数の機能を 1 つの PR にまとめると以下の問題が起きる:
- レビュアーが何を見ればよいか分からない
- 一部だけ revert したい時に切り出せない
- マージのタイミングが揃わないと部分機能だけ本番に出る
→ 「1 commit に閉じない単位で意味のある変更 = 1 PR」 を守る。
ブランチが長生きしないようにする
gantt
title ブランチの寿命: 良い例と悪い例
dateFormat YYYY-MM-DD
section 良い例
feature/login (3 日) :active, 2026-05-01, 2026-05-04
feature/search (2 日) :2026-05-05, 2026-05-07
fix/bug-123 (半日) :2026-05-08, 2026-05-08
section 悪い例 (長生き)
feature/big-refactor (60 日) :crit, 2026-03-01, 2026-04-30
長生きするほど main と乖離してコンフリクトが増える。目安: 1 ブランチ = 数日〜2 週間以内に merge。
大きい機能は小さな PR に分割するか、機能フラグ (feature flag) で本番では無効化したまま main に入れる。
ブランチ名のアンチパターン
避けるべき:
feature/new— 何の機能か分からないwip— 永続化しやすいyamada— 個人名のみだと用途不明fix— どの fix か区別不能
良い:
feature/sso-saml-integrationfix/login-redirect-empty-statechore/upgrade-django-5.1docs/operations-runbook
振り返り
- GitHub Flow = main + 短命 feature ブランチ。SaaS の連続デリバリ向き
- 1 機能 = 1 ブランチ = 1 PR の原則を守る
- branch protection rule で main を機械的に保護
- 1 ブランチは数日〜2 週間以内に merge。長生きさせない
- AI Agent ルールは「文章 + Hook」の二重防御
次のセクションでは、ローカル Git をリモート GitHub と繋ぐ操作を学びます。
参考リンク
- GitHub Flow 公式: https://docs.github.com/ja/get-started/using-github/github-flow
- Atlassian の Git Flow 解説: https://www.atlassian.com/ja/git/tutorials/comparing-workflows/gitflow-workflow
- ailms ブランチ保護: GitHub リポジトリ Settings → Branches
全 14 レッスンを、登録なしで無料で読めます。