#4 Git Flowブランチ戦略でチームの混乱を防ぐ - Python OSS開発記録
karrinn
著者
コミュニティヘルスファイルまで整備した、次は？「どのブランチで作業すればいいの？」で混乱させないために、ブランチ戦略を決めます。
今回はGit Flowを採用したwagtail-reusable-blocksを例に、ブランチの役割分担と命名規則を振り返ります。
KEY TAKEAWAYS
この記事でわかること
- Git Flowの7種類のブランチと役割分担
- GitHub Flow vs Git Flowの使い分け
- ブランチ戦略なしで起きる3つの悲劇
用語の定義
TERM 01
Git Flow
Vincent Driessen氏が2010年に提唱したブランチ戦略モデル。main・developの2本柱に、feature・fix・hotfixなどの短命ブランチを組み合わせる。
TERM 02
GitHub Flow
GitHubが推奨するシンプルなブランチ戦略。mainブランチ1本 + feature branchのみ。CI/CDが整備されてる環境向け。
TERM 03
Long-lived Branch
削除されず常に存在するブランチ。main（プロダクション）、develop（開発統合）など。Git Flowでは2本。
TERM 04
Short-lived Branch
作業完了後に削除される短命ブランチ。feature・fix・hotfix・chore・docsなど。マージしたら即削除が鉄則。
なぜブランチ戦略が必要？
前回までで、ドキュメントは整備しました。でも「どのブランチで作業すればいいの？」「mainに直pushしていいの？」が決まってないと、チームが混乱します。
実はこれも、OSSだけの話じゃなく、企業プロジェクトで超よく見る問題なんです。
悲劇1
「mainに直push → 本番が壊れる → 大惨事」
悲劇2
「みんながfeature/xxxで作業 → マージ地獄」
悲劇3
「緊急修正どこで？ → 探す時間で障害拡大」
解決策: ブランチ戦略を事前に決めて明文化すれば、この3つ全部解決します。
wagtail-reusable-blocksではGit Flowを採用。CONTRIBUTING.mdに書いたので、「どこにPR出せばいい？」の質問ゼロ。
Git Flow vs GitHub Flow
まず、どのブランチ戦略を採用するかを決めます。有名なのは2つ。
2つの選択肢
| 項目 | Git Flow | GitHub Flow |
|---|---|---|
| Long-lived Branch | main + develop（2本） | main のみ（1本） |
| リリースタイミング | 計画的リリース（月1回など） | いつでもリリース（mainマージ = デプロイ） |
| 向いてる |
・ライブラリ/パッケージ開発 ・バージョン管理が重要 ・複数バージョンサポート |
・Webアプリ ・CI/CD完備 ・継続的デプロイ |
| 複雑さ | やや複雑（ブランチ7種類） | シンプル（ブランチ2種類） |
| Hotfix対応 | hotfixブランチで即対応 | mainから直接修正 |
wagtail-reusable-blocks → Git Flow採用
結論から言うと、Git Flowを選びました。理由は3つ。
理由1
PyPIパッケージ開発 → バージョン管理重要
理由2
計画的リリース → v0.1.0、v0.2.0と段階的
理由3
複数バージョンサポート → v0.1.x系も保守
使い分けの目安
- Git Flow: ライブラリ・CLI・モバイルアプリ（リリース計画が必要）
- GitHub Flow: Webサービス・SaaS（デプロイ自動化済み）
- 迷ったらGitHub Flowから始めるのが無難（シンプルなので）
Git Flowの7種類のブランチ
Git Flowでは、役割ごとにブランチを使い分けます。wagtail-reusable-blocksでの実例を見ていきましょう。
ブランチの役割分担
Long-lived Branches（常に存在）
| ブランチ | 役割 | 保護 | デプロイ |
|---|---|---|---|
main | 本番リリース ・PyPI公開済みコード ・常に安定 ・タグ付け（v0.1.0など） | ✅ 必須 | PyPI公開 |
develop | 開発統合 ・次回リリース候補 ・feature/fixのマージ先 ・デフォルトブランチ | ✅ 必須 | TestPyPI |
Short-lived Branches（作業後削除）
| ブランチ | 用途 | Base | Merge To | 例 |
|---|---|---|---|---|
feature/* | 新機能開発 | develop | develop | feature/1-reusable-block-model |
fix/* | バグ修正 | develop | develop | fix/12-circular-reference |
hotfix/* | 緊急修正（本番） | main | main + develop | hotfix/15-security-patch |
chore/* | 雑務（設定・依存更新） | develop | develop | chore/update-dependencies |
docs/* | ドキュメント更新 | develop | develop | docs/api-reference |
ブランチ命名規則
wagtail-reusable-blocksでは、Issue番号を含めるルールにしました。
命名パターン
<type>/<issue-number>-<short-description> 例: feature/1-reusable-block-model fix/12-circular-reference-detection hotfix/15-security-patch chore/update-dependencies docs/fork-contribution-guide
Issue番号を含めるメリット
git branch -aで見ただけで、何のIssueか分かる- PR作成時に自動でIssueとリンクされる
- 後から「このブランチ何だっけ？」がなくなる
実際の開発フロー
理論は分かった、実際にどう動くかを見ていきましょう。
パターン1: 新機能開発
一番よくあるパターン。feature/xxxブランチで開発します。
流れ:
- developから新ブランチ作成
- 機能実装 + テスト
- PR作成（develop向け）
- レビュー → マージ
- ブランチ削除
# 1. developから新ブランチ git checkout develop git pull origin develop git checkout -b feature/11-reusable-block-model # 2. 実装 # ... コード書く ... git add . git commit -m "feat: add ReusableBlock model" # 3. Push & PR作成 git push origin feature/11-reusable-block-model # GitHub UIでPR作成（develop向け） # 4. マージ後、ローカルブランチ削除 git checkout develop git pull origin develop git branch -d feature/11-reusable-block-model
パターン2: 緊急修正（Hotfix）
本番でセキュリティバグ発見みたいな緊急事態。hotfix/xxxを使います。
特徴:
- mainブランチから作成
- main + developの両方にマージ
- 即リリース（v0.1.1など）
developにもマージする理由: hotfixの内容を次回リリースにも反映させるため。
# 1. mainから新ブランチ git checkout main git pull origin main git checkout -b hotfix/15-security-patch # 2. 修正 git add . git commit -m "fix: patch security vulnerability" # 3. mainにマージ git checkout main git merge hotfix/15-security-patch git tag v0.1.1 git push origin main --tags # 4. developにもマージ git checkout develop git merge hotfix/15-security-patch git push origin develop # 5. hotfixブランチ削除 git branch -d hotfix/15-security-patch
パターン3: リリース
developが安定したら、mainにマージしてリリース。
流れ:
- developからmainへPR
- 最終確認（テスト全部通ってる？）
- マージ
- タグ付け（v0.1.0）
- PyPI公開（GitHub Actionsで自動）
# 1. GitHub UIでPR作成 # develop → main # 2. マージ後、タグ付け git checkout main git pull origin main git tag v0.1.0 git push origin v0.1.0 # 3. GitHub Actionsが自動で: # - Release作成 # - PyPI公開 # - Release notes生成
ポイント: wagtail-reusable-blocksでは、タグをpushするとGitHub Actionsが自動でPyPI公開してくれます（次回以降の記事で解説）。
よくある間違いと対策
Git Flowを導入しても、使い方を間違えると意味がないです。よくある失敗例を見ておきましょう。
間違い集
間違い1: mainに直push
「小さい修正だから...」→ 本番破壊
対策:
mainを保護（次回トピック#5で設定）
間違い2: ブランチ消し忘れ
マージ後も残る → ゴミだらけ
対策:
PR設定で「マージ後自動削除」ON
間違い3: developからmainに直マージ
レビューなし → バグ混入
対策:
PR必須（保護設定で強制）
間違い4: 命名規則バラバラ
feature-xxx, feat/xxx混在
対策:
Rulesetsで命名強制（トピック#6）
すべて自動化で防げます
次回のトピック#5「GitHub Rulesetsでブランチ保護」で、これらの間違いを技術的に防止する方法を解説します。人の注意に頼らない仕組み作りが重要。
OSS vs 企業プロジェクト: Git Flowが果たす役割
OSS: 多様なコントリビューターの整理
OSSプロジェクトでは、様々なスキルレベルの人が参加します。
「どのブランチで作業すればいいの？」が明確でないと、混乱が生まれます。
Git Flowでブランチの役割を明確にすれば、初めての人でも迷わず作業できる。
「新機能ならfeature/」「バグ修正ならfix/」というルールがあるだけで、参加ハードルが下がります。
メリット
- 役割の明確化: ブランチ名を見ただけで「何の作業か」が分かる
- 並行開発: 複数の機能開発・バグ修正が同時進行できる
- リリース管理: mainブランチ = 常に本番環境デプロイ可能な状態
コントリビューターに優しい:
「このブランチで作業していいのかな？」と不安にならない。
ルールが明確なら、誰でも安心して参加できる。
企業: 「萎縮による開発効率の激減」を防ぐ
筆者が知る限り、日本の企業、特に大企業ほど深刻な問題があります。
「あれをやるな、これをやるとシステムが壊れる」と脅され続けた新人は、必要以上に慎重になります。
結果、開発効率が想像の何倍も下がる。異常なスローペースで開発が進むことになります。
問題の根本原因
- 不十分な説明: 何もかも漏れずに説明するのは難しい（記憶する方も無理）
- 脅しによる教育: 「これをやるとシステムが壊れる」と言われ続ける
- 萎縮: 新人は必要以上に慎重になり、「えいってやってみる」ができない
- 経験値が溜まらない: 失敗を恐れて試せないので、成長が遅い
Git Flowによる解決: 役割の明確化 = 心理的安全性
Git Flowでブランチの役割を明確にすれば、「どこで作業すればいいか」が分かる。
「feature/で作業すればいい」「mainには直pushしない」というルールが明確なら、安心して作業できる。
さらに、次回（Topic #5）で解説するGitHub Rulesetsによる技術的制限を組み合わせれば：
- システムで防御: mainに直pushしようとしても、システムが弾く
- 失敗しても大丈夫: 間違えたらシステムが教えてくれる
- えいってやってみることができる: 失敗を恐れずに試せる
- 経験値が遥かに溜まりやすい: 安心して失敗できる環境 = 成長が早い
安心して失敗できる環境:できることは何やってもいい。失敗したらシステムが弾いてくれる。
これは教育の本質です（筆者は過去、数年間IT系専門学校で担任をつとめ、システム開発関連科目の講義を担当していました）。失敗を恐れずに試せる環境こそが、人を育てます。
プロジェクト管理の責任
システム側の知識・理解がある人がプロジェクト管理をすべきです。
開発経験のない「マネジメントいっぱいしてきました」みたいな人に仕切らせてはいけません。
技術を理解していない人は、「人間に任せる」ことしかできない。
技術を理解している人は、「システムで防御する」ことができる。
重要:
Git Flowは「ルールを決める」だけ。次回のTopic #5で、技術的に間違いを防止する方法を実装します。
人間の記憶や注意に頼らない仕組み作りが、チーム全体の生産性を劇的に向上させます。
参考リンク
プロジェクト関連
- CONTRIBUTING.md - Branch Strategy - 実際のブランチ戦略
- Branches - 実際のブランチ一覧
- Network Graph - ブランチの可視化
公式ドキュメント
- A successful Git branching model - Git Flow提唱者の原典
- GitHub Flow - GitHubが推奨するシンプルな戦略
- Git Branching - Branching Workflows - Git公式ドキュメント
参考事例
- Wagtail Release process - Wagtail本体のリリースフロー
- Django Committing code - Djangoのブランチ運用
- Gitflow Workflow | Atlassian - Git Flow詳細解説
まだコメントはありません。最初のコメントを残しませんか？