この記事の目的
GitHubを使ってチーム開発を行う場合、GitFlowを正しく理解しておくことは大切です。
この記事では以下の2点を理解することができます。
- GitFlowとは何か
- GitFlowの要素
そこまで複雑ではないので、流れを抑えられればOKです。
GitFlowとは何か
GitFlowとはGitを使用してチーム開発する際のブランチの運用ルールです。
6種類のブランチを作成し運用するというルールが決まっています。
各ブランチの役割とマージの関係性を理解しておきましょう。
基本ルールは存在しますが、プロジェクトごとに調整されることがあります。その違いがあっても、基本を理解していれば対応可能です。
GitFlowではプロジェクトで作成するブランチの種類が決まっているので、その種類に沿ってブランチを作成し、開発を行っていくことになります。
GitFlowの要素（ブランチの種類）
1.main
- 「本番用の常に最新で安定しているブランチ」です
- このブランチには直接コミットせず、
release(後述)やhotfix(後述)からマージされることで更新されます
2.develop
- 「開発ブランチとも呼ばれ、機能ブランチ(後述)の変更をマージする」ブランチです
-
developはチーム開発の「開発中のコードの集約点」です - 機能開発が完了した
featureブランチ(後述)は必ずdevelopにマージされます - シンプルなプロジェクトでは省略されることもあり、その場合は
featureブランチから直接mainにマージする場合もあります - 大規模プロジェクトでは必須のブランチです
3.feature
- 「機能ブランチとも呼ばれ、機能ごとにいくつも作成されるブランチ」です
- ログイン画面、記事一覧画面、お問合せ画面など、パーツごとにいくつも作成されます
- ブランチ名には通常「
feature/ログイン画面」など、何の作業をするかが分かる名前をつけます - 開発者は主にこのブランチで作業することになります
4.hotfix
- 「本番（
main）で発生した緊急のバグを修正するブランチ」です - 修正完了後は、
mainだけでなくdevelopにもマージします - これにより、
developがmainと同期され、次回のリリースに影響を与えないようにします
5.release
- 「リリース準備用のブランチ」です
-
releaseブランチでは以下のような作業が行われます：
・バージョン番号の更新（例:1.0.0→1.0.1）
・軽微なバグ修正
・リリースノートの準備 - 作業完了後は、
mainとdevelopの両方にマージされます
6.support
- 「リリース後に行うサポート作業用のブランチ」です
-
supportブランチは必須ではなく、長期的なサポートが必要なプロジェクトで使用される場合があります - 例: 旧バージョンのバグ修正や互換性対応
まとめ
GitFlowの全体像
1.main→ 本番環境用。
2.develop → 開発中の変更を統合し、次回リリースの基盤。
3.feature/ → 新機能や改善作業用。
4.hotfix/ → 緊急バグ修正用。
5.release/ → リリース準備用。
6.support/ → 過去バージョンのサポート用（必要に応じて）。