ブランチとマージの仕組みは分かった。ところがチーム開発の話になると「うちは Git Flow で」「GitHub Flow が楽」「トランクベースにしたい」と型の名前が飛び交い、どれが自分たちに合うのか決められない。名前を暗記して選ぶと、状況が変わったときに理由を説明できません。この記事では型の名前ではなく、型の前にある「何を決めているのか」から選び方を組み立てます。
この記事の結論
- ブランチ戦略とは、どのブランチを長く置き、どれをすぐ消すかを決めるルールです。
- 長く置くブランチが増えるほど、統合の手間と衝突が増えます。置く理由があるときだけ増やします。
- 小さなチームで頻繁に出すなら、main と短命の作業ブランチだけの型から始めるのが素直です。
- 複数の版を並行して保守する、リリース前に長い検証期間がある、なら develop やリリースブランチを足します。
- どの型でも、main を守る約束とブランチを短く保つ約束が土台になります。
ブランチ戦略とは何を決めるものか
ブランチ戦略とは、リポジトリの中でどのブランチを長く置き、どれを作ってはすぐ消すかを決めた約束です。Git のコマンドは「枝を切る」「統合する」までしか教えてくれません。いつ切り、いつ統合し、誰が確認し、何を本番とみなすかは、チームが決めることです。
Git の公式ドキュメント（Pro Git）は、ブランチの使い方を2種類に分けて説明しています。
- 長く置くブランチ: 安定度の段として使うもの。たとえば完全に安定したコードだけを置く段と、その手前でテストする段を分け、安定したと判断できたら上の段へ進める、という使い方です。
- トピックブランチ: 1つの機能や修正のために切る短命のブランチ。終われば取り込んで消します。
戦略の違いは、突き詰めるとこの2種類の配分の違いです。長く置くものが少なければ構造は単純で、多ければ段階的に守れる代わりに、段をまたぐ統合の手間が増えます。
3つの型を並べて見る
よく使われる呼び方で、型を3つに分けて眺めます。名前の細かな定義は資料によって違うので、ここでは「長く置くブランチの数」で整理します。
| 型 | 長く置くブランチ | 作業の流れ | 向きやすい場面 |
|---|---|---|---|
| main ＋ 短命ブランチ | main の1本 | 作業ブランチを切る → レビュー → main に入れて消す | 小さなチーム、頻繁に出す |
| develop を置く型 | main ＋ develop（＋リリース用） | 作業は develop に集め、出す時期に main へ | 出す時期が決まっている、検証期間がある |
| main に小さく頻繁に入れる型 | main の1本 | ごく小さな変更を、ほぼ毎日 main へ | 自動テストが厚い、出す頻度が高い |
1つ目と3つ目はどちらも長く置くのは main だけで、違いは作業ブランチの「寿命」です。2つ目は、main の手前に「統合の段」を1つ置いています。Pro Git が言う安定度の段に近い形です。
LONG OR SHORT長く置くか、短く保つか
長く置くブランチが少ないほど、統合の手間は軽い
長く置くブランチが多い型
main・develop・リリース用など
- ブランチの数多い。段ごとに役割がある
- 統合の回数段をまたぐぶん増える
- 向く場面複数の版の保守、長い検証期間
長く置くブランチが少ない型
main ＋ 短命の作業ブランチ
- ブランチの数main の1本だけが長く残る
- 統合の回数小さく頻繁に、軽く済む
- 向く場面小さなチーム、頻繁に出す
CHECK 1ここまでの確認
ブランチ戦略が決めることとして最も近いのはどれ?
答えと解説
答え: 2. どのブランチを長く置き、どれをすぐ消すかのルール
ブランチ戦略はコマンドの覚え方ではなく、チームの運用の約束です。読み直すなら「ブランチ戦略とは何を決めるものか」の章へ。
どの型を選ぶか？ 判断の軸は「人数・出す頻度・並行して保守する版の数」
型を選ぶ問いは3つに絞れます。
THREE QUESTIONS型を選ぶ3つの問い
型は名前ではなく3つの問いで選ぶ
-
1.何人が同じコードを触るか
増えるほど、ブランチを短く保つ約束が効く
-
2.どれくらいの頻度で出すか
頻繁なら main をそのまま出せる状態に保つ
-
3.並行して保守する版はあるか
あるなら、版ごとに修正を入れる先を置く
何人が同じコードを触るか
人数が少ないほど、誰が何を変えているか把握しやすく、統合の段を挟む必要が薄くなります。人数が増えるほど、同じ箇所を同時に触る確率が上がるので、変更を小さく早く入れる約束の重みが増します。ここで注意したいのは、人が増えたら develop を足す、という単純な話ではないことです。人が増えたときこそ、作業ブランチを短く保つ方が衝突を減らします。
どれくらいの頻度で出すか
出す頻度が高いなら、main がそのまま出せる状態であることが前提になります。main の手前に段を置くと、その段を通る時間だけ出荷が遅れます。出す時期が決まっていて、その前に検証期間を取る製品なら、検証用の段を置く理由になります。
並行して保守する版はあるか
本番で複数の版を同時に支える必要があるなら、版ごとに修正を入れる先が要ります。Git 公式の gitworkflows は、修正は古い保守ブランチ（maint）に入れ、そこから新しい側へマージしていく考え方を説明しています。こうすると同じ修正を版ごとに書き直さずに済みます。この場合、長く置くブランチが増えるのは自然で、置く理由がはっきりしています。
3つの問いの答えが「少人数・頻繁・版は1つ」なら main ＋短命ブランチ、「版が複数」「検証期間あり」なら段を足す、と読めます。どれか1つが当てはまらない中間もあるので、足すのは理由が1つ見つかるごとに1本にします。
CHECK 2ここまでの確認
本番で2つの版を並行して保守する必要がある。ブランチを増やす理由になるか?
答えと解説
答え: 1. なる。版ごとに修正を入れる先が要るから
版ごとに修正を入れる先が必要になるため、長く置くブランチを足す理由になります。読み直すなら「どの型を選ぶか」の章へ。
長く置くブランチが増えると何が起きるか
長く置くブランチが増える、または作業ブランチが長生きすると、次の悪循環が起きやすくなります。
VICIOUS CYCLE長く置く悪循環
ブランチを長く置くほど統合は重くなる
統合の遅れ
差が積み重なる
- 長く置く短く切って早く入れる
- 差が広がる
- 統合が重い
- 後回しにする
- 差が広がる: 作業ブランチを切った後も、main には他の人の変更が入り続けます。期間が長いほど差は大きくなります。
- 統合が重くなる: 差が大きいと衝突（コンフリクト）が増え、直したあとの動作確認もやり直しになります。
- 後回しにしたくなる: 統合が重いと、キリのいいところまで入れたくなり、ブランチがさらに長生きします。
- 環境とのずれ: 長く置いたブランチは、本番やテスト環境の状態とずれた前提でテストされがちです。統合してはじめてずれに気づきます。
断ち切る点は、ブランチを短く切って、早く入れることです。1つの作業を小さく分けるほど、1回の統合は軽くなります。段を増やすのは安全に見えますが、段をまたぐ統合の回数も増えるので、手間は別の形で戻ってきます。
CHECK 3ここまでの確認
作業ブランチを何週間も main に入れないでおくと、起きやすいことはどれ?
答えと解説
答え: 1. 差が広がり、統合時の衝突とやり直しが増える
その間に main 側へ他の変更が積み重なるためです。自動で追いつくことはありません。読み直すなら「長く置くブランチが増えると何が起きるか」の章へ。
どの型でも決めておくこと
型が違っても、土台になる約束は共通です。
| 決めること | 例 | 理由 |
|---|---|---|
| main の保護 | 直接 push しない。レビューとテストを通ったものだけ入れる | 本番に近いブランチを壊さないため |
| ブランチ名 | 目的が分かる名前（機能・修正・調査など）を揃える | 何のブランチか、消してよいか判断できるように |
| 消すタイミング | マージしたら消す | 古い枝が溜まると、どれが生きているか分からなくなるため |
| マージの方法 | 履歴をそのまま残すか、1つにまとめるかを決める | 後から履歴を読む人の手間が変わるため |
| ブランチの寿命の目安 | 日数・週数など、チームで決めた上限 | 差が広がる前に、分割を促すため |
どれも GitHub の画面の設定名に依存しない約束として書いています。実際の設定の場所や名前は改定されるので、公式ドキュメントで確認してください。
学習用リポジトリと、CI/CD につなぐときの考え方
ひとりの学習用リポジトリでも、最小限の約束は役に立ちます。main を直接触らず、作業ブランチを切り、プルリクエストで取り込み、取り込んだら消す。この流れを習慣にしておくと、チーム開発に入ったときに型の違いだけを学べば済みます。
CI/CD につなぐときは、ブランチ戦略が「どのブランチに何が起きたら、何を自動で流すか」の前提になります。たとえば、作業ブランチでは検査だけを流し、main に入ったら出荷の準備まで流す、といった割り当てです。長く置くブランチが多いほど、自動化の対象も増えます。ビルドとテストが自動で流れていれば、main を守る約束も、ブランチを短く保つ約束も、人の注意力に頼らずに守れます。仕組みの全体は次の記事で扱います。
READ ALSO — 学習中向け・段2 構成
CI/CD の仕組み｜コミットから本番まで、ビルド・テスト・デプロイが自動で流れて止まる理由
まとめ
- ブランチ戦略は流行りの型ではなく、長く置くブランチとすぐ消すブランチの配分を決める設計です。
- 選ぶ軸は、人数・出す頻度・並行して保守する版の数の3つです。
- 長く置く理由がないブランチは増やさず、作業ブランチは短く保ちます。
- 型が違っても、main を守る約束とブランチを短く保つ約束は共通です。
Cloudory 執筆者（AWS 認定 全冠）
型の名前を知っていることより、「なぜこのブランチを置くのか」を一言で言えることのほうが、チームで話すときに役に立ちます。置く理由が言えないブランチは、まず外せないかを考えてみてください。
参照ソース
- Pro Git: Branching Workflows — 長く置くブランチ（安定度の段）とトピックブランチ（短命）の考え方の根拠。
- gitworkflows（Git 公式ドキュメント） — 統合ブランチへ段階的に進める考え方、修正を古い保守ブランチから新しい側へマージする点の根拠。
