GitFlow とは？

Git自体はブランチの使い方を決めてくれない。GitFlowは「どのブランチをどう使うか」のルールを決めた運用モデルだよ。main、develop、feature、release、hotfixの5種類のブランチに役割を割り当てて、開発からリリースまでの流れを明確にする。

mainは本番環境と同じ状態。developは開発の統合先。featureはdevelopから分岐して1機能を作る作業用。releaseはdevelopからリリース準備のために切り出す。hotfixはmainから緊急のバグ修正用に分岐する。featureとreleaseは終わったらdevelopにマージし、releaseとhotfixはmainにもマージする。

mainは「いつでもリリースできる状態」を保つことが大原則。直接コミットすると未完成のコードや検証されていない変更が入ってしまう。releaseブランチやhotfixブランチを経由することで、品質を担保してからmainに反映するんだ。

developで開発した機能がある程度たまったら、releaseブランチを作ってリリース準備をする。バージョン番号の更新、ドキュメント修正、最終テストをここで行う。この間もdevelopでは次のバージョンの開発を続けられるのがポイントだよ。

提唱者自身が2020年に「Web系の継続的デリバリーならGitHub Flowの方がシンプルでいい」と追記したくらいだからね。GitFlowはリリースサイクルが数週間〜数ヶ月の製品（モバイルアプリやパッケージソフト）には向いているけど、毎日何回もデプロイするSaaSには重すぎる。

チームの状況次第だね。CI/CDで頻繁にデプロイするならGitHub Flow（mainとfeatureだけ）がシンプルでいい。リリースバージョンの管理が必要ならGitFlowが活きる。最近はトランクベース開発といって、短命のfeatureブランチだけを使い、フィーチャーフラグで本番リリースをコントロールする手法も増えている。大事なのは「チームの開発・リリースサイクルに合った戦略を選ぶ」ことで、ブランチモデルに正解は1つじゃないんだ。