`main` と `develop` を常設し、`feature/*`・`release/*`・`hotfix/*` を目的別に切り分けます。複数人の並行開発を整理できます。
歴史
502
Git Flow
ギット フロー
体験区分：少しだけ触った
推奨読者レベル：Level 3-4
何をしてくれるか
どこで出会うか
チーム開発のオンボーディング資料やブランチ命名規則の説明で目にします。「うちは Git Flow を採用している」とは、このモデルのブランチ管理を指します。
比較図
2026.04·ready
「Git Flow をやめて GitHub Flow にしたら、AI の PR で詰まらなくなりました。」
Git Flowの見方
503
この用語の見どころ
1
役割
git リポジトリでのブランチ運用を体系化したモデルです。
2
うれしさ
ブランチの目的が明確で、複数人の並行作業を整理しやすいです。
3
注意点
提案者本人が 2020 年に「継続デプロイには複雑すぎる」と注釈を出しています。
4
どこで役立つか
バージョン管理が必要な製品や、リリース日が決まっている開発に向きます。
5
はじめに
git の標準ではなく、選択肢の 1 つである点を押さえておきます。
6
深掘り先
GitHub Flow、Trunk-Based Development、CI/CD
非エンジニアのつまずき
- そもそも馴染みのない言葉で、図を見ても自分の作業にどう紐づくのかが掴みにくいです
私のコメント
- 第一印象:今回初めて聞いた言葉です
- 良い点:ブランチ運用の形としては綺麗にまとまっている感じがあります
- ダメな点:人間が運用すると認知コストが高く、ひとり開発だと過剰になりがちです
- 誰向けか:チームで明確なリリース管理が必要な現場向けで、個人開発には重い印象です
開発フローでの位置
機能着手
統合
リリース準備
本番反映
緊急修正
関連用語
H-06·workflow
バイブコーディング図鑑