Stage 3・上級編ー　Lesson 3-6

feature ブランチ運用 — main / develop / feature の使い分け

main は本番、develop は開発統合、feature は1機能ずつ。ブランチを役割で分ける

💡 たとえるなら

本番用セーブ列・開発用セーブ列・機能ごとの実験セーブ列と、役割でルートを分けて管理する

これまでに ブランチ・マージ・コンフリクト・rebase といった部品を学んできました。最後に、それらを チーム開発の現場でどう組み合わせるか を見ていきます。1人開発でも応用できる定番フローです。

なぜブランチを役割分けするのか

main ブランチに直接コミットしていく方式（trunk-based）も悪くないのですが、規模が大きくなると：

「いま main は本番に出せる状態？」が分からなくなる
複数人の作業がぶつかりやすい
リリースタイミングを揃えにくい

そこで、ブランチに 明確な役割 を与えて整理する運用が広まりました。

3階層モデル：main / develop / feature

①切る ②開発 ③マージ ④リリース

①〜④の順に流す。複数 feature を同時に走らせるときも同じ流れ

ブランチ	役割
main	本番（リリース版）。常に「今動くもの」
develop	開発の統合場所。次のリリースに向けた最新
feature/<名前>	1機能ごとの作業ブランチ。短命で OK

軽量な運用なら main + feature の2階層 でも十分機能します。develop は規模が大きい・リリースサイクルがゆっくりな場合に追加。

1機能を進めるフロー

「ログイン機能」を追加する例で1サイクル見てみます。

① develop の最新を取得

$ git switch develop
$ git pull origin develop

② feature ブランチを切る

$ git switch -c feature/login

ブランチ名は feature/login のようにスラッシュ区切りで分類するのが慣習。bugfix/...、hotfix/... も同じパターン。

③ 機能を作って細かくコミット

$ git add .
$ git commit -m "ログインフォームのUIを追加"
$ git commit -am "認証API呼び出しを追加"
$ git commit -am "エラーメッセージ表示を実装"

④ 自分のブランチをリモートに push

$ git push -u origin feature/login

⑤ develop の最新を取り込む（rebase または merge）

機能を作っている間に develop が進んでいる可能性があります。取り込んでから合流する のがマナー。

＃ develop の最新を fetch
$ git fetch origin develop
＃ feature の上に develop の新コミットを取り込む（rebase 派）
$ git rebase origin/develop
＃ または、merge派ならこちら
$ git merge origin/develop

⑥ develop に取り込む（マージ）

最終確認したら、develop に戻って merge：

$ git switch develop
$ git pull origin develop
$ git merge --no-ff feature/login
$ git push origin develop

--no-ff は「fast-forward しない」設定。常にマージコミットを作って 「どの feature を統合したか」 を履歴に残します。

⑦ feature ブランチを削除

$ git branch -d feature/login
$ git push origin -d feature/login

ローカルとリモート、両方掃除。

リリースの瞬間：develop → main

リリースタイミングが来たら develop を main にマージ：

$ git switch main
$ git merge --no-ff develop
$ git tag -a v1.2.0 -m "v1.2.0 リリース"
$ git push origin main --tags

タグでリリース版に目印をつけるところまでがワンセット。

ブランチ命名の慣習

役割をプレフィックスで揃えると見通しが効きます：

プレフィックス	用途
`feature/...`	新機能
`bugfix/...`	バグ修正（develop に向けて）
`hotfix/...`	本番の緊急修正（main に向けて）
`release/v1.2.0`	リリース準備用の安定化ブランチ
`chore/...`	雑務（リファクタ・依存更新など）

ホットフィックス（緊急修正）の例外フロー

「本番でバグ発見、すぐ直したい」場合だけ、main から直接ブランチを切ります：

＃ ① main から hotfix ブランチを切る
$ git switch main && git pull origin main
$ git switch -c hotfix/login-bug
＃ ② バグを修正してコミット
$ # （コードを修正）
$ git commit -am "ログイン画面の落ちるバグを修正"
＃ ③ main に取り込んで push → タグ付けてリリース
$ git switch main
$ git merge --no-ff hotfix/login-bug
$ git tag -a v1.2.1 -m "hotfix: ログイン画面の落ちるバグを修正"
$ git push origin main --tags
＃ ④ develop にも同じ修正を取り込む（重要！）
$ git switch develop && git merge --no-ff hotfix/login-bug
$ git push origin develop
＃ ⑤ hotfix ブランチを掃除
$ git branch -d hotfix/login-bug

ステップ④を忘れると、次のリリースで 同じバグが復活 するので注意。develop にも必ず取り込みます。

軽量版：main + feature の2階層

少人数や個人プロジェクトでは develop を省くのが現実的：

main だけ。常に「リリースできる状態」を保つ
機能ごとに feature/... を切って、できたら main にマージ
リリース時は main に tag を打つ

GitHub Flow と呼ばれる方式で、シンプルで速い。

このレッスンのまとめ

できるようになったこと

✅ main / develop / feature の役割分担を理解した

✅ feature ブランチでの1機能フロー（branch → commit → rebase → merge → delete）を回せる

✅ --no-ff でマージコミットを残す意味がわかった

✅ ホットフィックスの例外フローを覚えた

✅ 軽量版（main + feature）も選択肢にできる

✏️ 理解度チェック

0 / 3 正解

各問題、選んだ瞬間に正解と解説が表示されます。気軽に試してください。

Q1. feature ブランチの典型的な役割は？
Q2. main に直接コミットする運用が推奨されない主な理由は？
Q3. develop ブランチの典型的な役割は？