import { NavigationBlock } from "@/components/blog/NavigationBlock";
ブランチ戦略の超入門｜main / feature / release の役割と最小ルール
ブランチ戦略で迷うのは、「ブランチをいくつ作るか」「いつどのブランチに何を入れるか」の判断軸がないからです。
軸がないと、main に直接書いて事故る、ブランチが乱立してマージが追いつかない、といった失敗が起きやすくなります。
この記事が想定する読者：Web制作・開発の現場で、技術選定や改善の判断軸を持ちたい方。情報収集で止まらず、前提・優先順位・次の一手まで整理したい担当者。
判断を誤るとどうなるか：一般論の理解だけで終えると、自社の制約（スタック・工数・運用体制）とずれて選定や実装が空回りしやすい。前提・撤退線・次の一手まで言語化してから進めると判断がぶれにくくなります。
この記事では、main / feature / release の3本立てを「役割」と「いつ使うか」で整理します。深い理解のため、「なぜ main を守るか」「なぜ feature で分けるか」「release の意味」もセットで解説します。
この記事を読む前に
ブランチの「何を分岐させるか」の基礎は、ブランチとは？で押さえておくと理解が深まります。分岐した変更を戻す操作は、マージとは？で整理しています。コミットをどの単位で切るかは、コミットメッセージの型と合わせて読むと、運用全体の判断がしやすくなります。
なぜ「戦略」が必要か：main を守る理由
main（または master） は、本番に反映される（または反映する予定の）コードの基準です。
ここに直接書くと、次のような失敗が起きやすくなります。
- 未完成の変更が本番に入る：テストやレビューが抜けたままデプロイされる
- 複数人の変更がぶつかる：誰が何を変えたか分からず、コンフリクトや不整合が増える
- 「いつでも戻せる」が効かなくなる：main が壊れた状態で進むと、戻すポイントが分からなくなる
失敗像：main に直接書く運用を続けると、「動いていたのに動かなくなった」「誰の変更で壊れたか分からない」が繰り返し、手戻りとストレスが増えます。
この記事の仮説：main を「常にデプロイ可能な状態」に保ち、新しい変更は feature で分岐してからマージする、という最小ルールで、事故と手戻りが減る。
3本の役割：main / feature / release
小チームでも理解しやすい最小構成は、次の3本です。
| ブランチ | 役割 | いつ使うか |
|---|---|---|
| main | 本番の基準。常に「デプロイ可能」な状態を保つ | 常に存在。ここに直接コミットしない（原則） |
| feature | 新機能・バグ修正・リファクタなど「1つの論点」を開発する | 作業を始めるときに main から分岐。完了したら main にマージ |
| release | 本番リリース前の最終確認・調整用（オプション） | リリース作業を始めるときに main から分岐。問題なければ main にマージし、本番に出す |
main：本番の基準を守る
- 役割：本番環境に反映する（または反映する予定の）コードの唯一の基準。
- ルール：直接コミットしない。変更は必ず feature（または release）で行い、レビュー・テスト後にマージする。
- 理由：main に直接書くと、「未完成の変更が混ざる」「誰が何を変えたか追えない」が起きやすく、本番が壊れたときに戻す判断が難しくなります。
feature：1つの論点を分岐して開発する
- 役割：新機能・バグ修正・リファクタなど、1つの論点を安全に開発する場所。
- ルール：作業を始めるときに main から分岐する。作業が終わったら main にマージし、分岐ブランチは削除してよい（運用による）。
- 理由：main を触らずに試行錯誤できる。失敗しても main に影響しない。完了した変更だけを main に戻せる。
命名の例：feature/ユーザー登録 fix/ログインエラー refactor/検索処理 など、何の作業かが分かる名前にすると、後から見たときに判断しやすくなります。
release：リリース前の最終確認用（オプション）
- 役割：本番リリース直前の最終確認・軽微な調整用。main にマージする前の「出荷前チェック」に使う。
- ルール：リリース作業を始めるときに main から分岐。バージョン番号の更新・軽微な修正だけをここで行い、問題なければ main にマージ。本番デプロイは main から行う。
- 理由：main で「今リリースするかどうか」の判断をせずに済む。リリース作業中に別の feature が main にマージされても、release ブランチには影響しない（必要に応じて main を release に取り込む）。
小チームでは省略可：リリースが「main をそのままデプロイする」だけなら、release ブランチは作らず、main の状態でリリースしてよいです。複数人でリリース作業を並行するときや、リリース前の調整が増えてきたときに導入すると効きます。
流れのイメージ：feature から main へ
- main の状態：本番と一致した「デプロイ可能」な状態。
- feature を分岐：
git checkout -b feature/〇〇 mainのように、main から feature ブランチを作る。 - feature で開発：コミットを重ね、テスト・レビューを通す。
- main にマージ：問題なければ main にマージ。PR（プルリクエスト）を使う場合は、PR をマージする。
- feature は削除：マージ済みの feature ブランチは削除してよい（運用による）。main に統合されたので、分岐は不要になる。
深い理解：main に「完成した変更だけ」が入るようにすると、「main のどの時点でも本番に戻せる」状態を保てます。feature で失敗しても main は壊れないので、安心して試行錯誤できます。
小チームで最低限守るルール
ブランチ戦略を複雑にしすぎないための最小セットです。
- main に直接コミットしない：変更は必ず feature で行い、マージで main に反映する。
- 1 feature ＝ 1つの論点：1つの機能・1つの修正・1つのリファクタ。複数論点を1本にしない。
- main にマージする前に pull する：main が進んでいれば、最新の main を取り込んでからマージする。コンフリクトを減らす。
- マージ前にテストを通す：main に「動かない変更」が入らないようにする。
この4つをチームの開発ルールに明文化し、レビューやマージのタイミングで軽く確認するだけで、main の安定性と履歴の分かりやすさが持続します。
よくある質問
main と master の違いは？
役割は同じです。歴史的に master が使われていましたが、近年は main が推奨されることが多いです。チームでどちらか一方に統一していれば問題ありません。
feature は何本まで作っていい？
論点の数だけ作ってよいです。ただし1人で複数本を同時に進めすぎると、どの feature がどの状態か分からなくなりやすいです。1本ずつ完了させて main にマージし、次の feature に進む運用が分かりやすいです。
release は必ず必要？
いいえ。小チームで「main をデプロイするだけ」なら release は省略してよいです。リリース前の調整が増えてきたら、release ブランチを導入するかを検討します。
ブランチが乱立して追いつかないときは？
「1 feature ＝ 1論点」が守られていない、またはマージが遅れて feature が積み上がっている可能性があります。未完了の feature を整理し、優先度の高いものから main にマージして片付け、同時に進める feature の数を減らすと追いやすくなります。
ブランチ戦略の要点（main・feature・いつ切るか）
- main は本番の基準。直接コミットせず、常に「デプロイ可能」な状態を保つ。
- feature は1つの論点を開発する場所。main から分岐し、完了したら main にマージする。
- release はリリース前の最終確認用（オプション）。小チームでは省略してよい。
- 小チームの最小ルール：main に直接書かない／1 feature＝1論点／マージ前に pull／マージ前にテスト。
関連記事
- ブランチとは？：ブランチの基礎と「何を分岐させるか」
- マージとは？：分岐した変更を main に戻す考え方
- コミットメッセージの型：feature で切る「1論点」の単位
- プル（pull）とは？：main の最新を取り込む操作
- コミットとは？：コミットの基礎
nextInCategory={[ { title: "コミットメッセージの型（最小ルール）｜履歴が読める・戻せる書き方", url: "/blog/web/commit-message-style-guide" }, { title: "ブランチとは？超初心者向け完全ガイド", url: "/blog/web/what-is-branch-beginners-guide" }, { title: "Gitのコミットとは？実務で迷わない\"コミットメッセージの型\"と最低限のルール", url: "/blog/web/what-is-commit-beginners-guide" }, { title: "Gitとは？超初心者向け完全ガイド", url: "/blog/web/what-is-git-beginners-guide" }, ]} philosophyLink={true} />