はじめに
Gitのブランチ戦略について調べると、
-
Git Flow / GitHub Flow / Trunk Based… 種類が多すぎる
-
結局どれを使えばいいのかわからない
-
現場で「なんとなく」決まっている
と感じることが多いです。
この記事では、
「ブランチ戦略とは何か」から「どういう時にどれを使うか」まで整理します。
ブランチ戦略とは何か
ブランチ戦略とは、
「誰が・いつ・どのブランチで・何をするか」を決めるルール
です。
単にブランチを切る話ではなく、
-
本番に影響を出さない
-
複数人で安全に開発する
-
レビュー・テスト・リリースを整理する
ための チームの交通ルール です。
なぜブランチ戦略が必要なのか
ブランチ戦略がない（または形骸化している）と、次の問題が起きます。
-
本番に未完成コードが混ざる
-
誰がどこで作業しているかわからない
-
レビューが形だけになる
-
新人が毎回ルールを聞く
→ チーム開発では必須の設計要素 です。
ブランチ戦略を考える上で大事なこと
技術より先に、次を考える必要があります。
1. 誰が使うか
Git初心者はいるか
メンバーの入れ替わりは多いか
2. 壊れたらどれくらいヤバいか
本番障害＝即クレームか
社内ツールで多少OKか
リスクが高いほどクッションが必要
3. CI・レビューはあるか
PRレビューは必須か
自動テストは回っているか
CIが弱いなら main 直マージは危険
4. リリース頻度
毎日 / 週1 / 月1
頻繁ならシンプル、少ないなら慎重に
代表的なブランチ戦略と使い分け
GitHub Flow
構成
main
└─ feature/*
流れ
1.main から feature/* を作成
2.実装後にPR作成
3.レビュー & CI通過
4.main にマージ → デプロイ
向いているケース
-
Webアプリ / SaaS
-
小〜中規模チーム
-
CIが最低限回っている
-
リリース頻度が高い
特徴
-
ルールがシンプル
-
理解しやすい
main + develop
構成
main（本番）
develop（結合・検証）
└─ feature/*
流れ
1.feature/* → develop
2.検証後、develop → main
向いているケース
-
手動テストが多い
-
リリースが週1〜月1
-
本番直前でまとめて確認したい
特徴
-
本番へのクッションがある
-
炎上しにくい
Git Flow
構成
main
develop
feature/*
release/*
hotfix/*
向いているケース
-
大規模チーム
-
リリース日が厳密に決まっている
-
承認フローが重い
注意点
小規模ではオーバースペック
運用できていない現場も多い
Trunk Based Development
構成
main（trunk）
向いているケース
-
CI・テストが非常に強い
-
デプロイ頻度が高い
-
全員がGitに慣れている
まとめ
-
ブランチ戦略は「チームの交通ルール」
-
技術より 人・リスク・運用 を見る
-
迷ったら GitHub Flow
ブランチ戦略に 唯一の正解はありません。
大事なのは、その戦略を、チーム全員が説明できて守れるか*
この記事が、「なんとなくGit」を卒業するきっかけになれば嬉しいです。