developブランチとは？featureブランチの意味とrelease・hotfixとの違い【Git Flow】

developブランチは、次のリリースに入れる変更を集めておく「統合ブランチ」です。2010年にVincent Driessen氏が公開したブランチモデル「A successful Git branching model」（通称Git Flow）で定義されました。本番に出ている状態を保つmain（旧master）と並んで常に存在し、機能開発のfeatureブランチはここから切ってここへ戻します。

この記事では、developとmain・feature・release・hotfixの分岐元とマージ先の違いを原典に沿って整理し、実際のgitコマンドで一巡を示します。そのうえで、GitHubでdevelopを既定ブランチにするかどうかで挙動が変わる点と、developを置かない運用を選ぶべき条件まで扱います。「ブランチ」という仕組みそのものの説明はブランチとは？バージョン管理で開発を分岐させる仕組みにまとめています。

まとめ：developブランチとGit Flowの5種類のブランチの要点

• developは「次のリリースに入る変更」が集まる統合ブランチ。mainは「本番に出ている状態」を表す。どちらも削除しない常設のブランチ。
• featureはdevelopから切ってdevelopへ戻す。releaseはdevelopから切り、mainとdevelopの両方へ戻す。hotfixだけはmainから切り、mainとdevelopの両方へ戻す。
• 原典の例外として、releaseブランチが存在する間のhotfixはdevelopではなくreleaseへ戻す。
• マージは --no-ff でマージコミットを残すのが原典の方式。機能単位で履歴を追え、まとめて取り消しやすくなる。
• GitHubでは、Issueの自動クローズ・Dependabotの更新先・scheduleで動くワークフローが「既定ブランチ」を基準にする。developとmainのどちらを既定にするかを最初に決める。
• 継続的にデプロイするWebサービスでは、原典の著者自身が2020年に、より単純なGitHub Flowを勧めている。developが要るのは、版番号を付けて出すソフトや複数バージョンを並行保守する場合。

developブランチの役割とmainとの違い

原典は、中央リポジトリに「無期限に存在する2本のメインブランチ」としてmasterとdevelopを置きます。masterは常に本番リリースできる状態、developは次のリリースに向けて開発が済んだ最新の変更が入った状態を表す、と定義しています。原典はdevelopを「integration branch（統合ブランチ）」とも呼び、毎晩の自動ビルド（ナイトリービルド）はここから作るとしています。

developの変更が安定し、リリースできる状態になったら、releaseブランチを経由してmainへマージし、リリース番号のタグを付けます。原典は「masterへマージされたら、それは定義上、新しい本番リリースである」という扱いです。つまりmainの履歴はリリースの履歴そのものになり、developには開発途中の変更が積み上がります。

「devブランチ」「開発ブランチ」と呼ぶチームもありますが、役割は同じです。名前はGitの決まりではなく運用上の約束なので、チームで1つに統一しておけば足ります。

Git Flowの5種類のブランチ：分岐元・マージ先・命名規則

原典はmainとdevelopのほかに、寿命の限られた3種類の補助ブランチ（feature・release・hotfix）を定義しています。どれも技術的にはただのGitブランチで、違いは「どこから切り、どこへ戻すか」という使い方だけです。

原典の命名は release-1.2 のようなハイフン区切りです。一方、git-flowのコマンドラインツールは feature/・release/・hotfix/ というスラッシュ区切りの接頭辞を既定にしており、現在はこちらの形が広く使われています。

featureブランチの意味：機能ごとにdevelopから切り、developへ戻す

featureブランチは、新しい機能や改修を開発するための作業用ブランチです。原典では「トピックブランチ」とも呼ばれ、分岐元はdevelop、マージ先もdevelopに限られます。機能が完成したらdevelopへマージし、期待外れの実験に終わったらマージせずに捨てます。

原典には「featureブランチは通常、開発者のリポジトリにだけ存在し、中央（origin）には置かない」とあります。2010年当時の前提で、現在はプルリクエストでレビューするためにfeatureブランチをリモートへpushするのが一般的です。この点は原典と今の運用がずれている箇所です。

名前は feature/login-form のように、接頭辞と作業内容を組み合わせるのが定番です。チケット番号を入れる（feature/123-login-form）と、Issueやタスク管理との対応が名前だけで分かります。

releaseブランチ：版番号を決めて凍結し、mainとdevelopへ戻す

releaseブランチは、リリース直前の仕上げをするブランチです。版番号の更新、軽微なバグ修正、リリース用のメタデータの準備をここで行い、その間もdevelopは次の機能を受け入れ続けられます。

原典の要点は3つあります。まず、releaseを切るのは、developが次のリリースの状態を（ほぼ）反映した時点です。そのリリースに入れる機能はすべてマージ済みでなければならず、先のリリース向けの機能はrelease作成後まで待ちます。次に、版番号が決まるのはreleaseブランチを切った瞬間で、それより前にdevelopの変更が0.3になるのか1.0になるのかは決まっていません。最後に、releaseブランチで大きな新機能を追加することは「厳しく禁止」されています。

完成したreleaseはmainへマージしてタグを付け、同じ内容をdevelopにもマージします。原典は、このdevelopへのマージで版番号の変更がぶつかり、コンフリクトが起きる可能性が高いと明記しています。解消の手順はコンフリクトとは？Gitで変更が衝突する仕組みと解消手順を参照してください。

hotfixブランチ：補助ブランチで唯一mainから切る理由と例外ルール

hotfixブランチは、本番で見つかった重大な不具合を急いで直すためのブランチです。補助ブランチ3種類の中で唯一、developではなくmainから切ります。developにはまだ出せない開発途中の変更が入っているため、本番と同じ状態から修正を始める必要があるからです。

修正が済んだらmainへマージしてタグを付け、developにもマージして次のリリースに修正を引き継ぎます。原典には例外があり、releaseブランチが存在する間は、hotfixをdevelopではなくreleaseブランチへ戻します。releaseが完了してdevelopへマージされるときに、修正も一緒にdevelopへ入るためです。ただし、develop側ですぐに修正が必要なら、そのままdevelopにもマージしてかまわないとしています。

hotfixをmainにだけ入れてdevelopに戻し忘れると、次のリリースで同じ不具合が再発します。原典がhotfixの完了時に、mainに続けてdevelopへのマージを求めているのはこのためです。

コマンドで見るGit Flowの一巡：featureからhotfixまで

Git Flowは専用ツールがなくても、通常のgitコマンドで運用できます。原典の手順を、現在の git switch で書き直すと次のとおりです。ブランチ名は例です。

# developを用意する（初回のみ）
git switch -c develop main
git push -u origin develop

# 1. featureブランチで機能を開発し、developへ戻す
git switch -c feature/login-form develop
# ...コミットを重ねる...
git switch develop
git merge --no-ff feature/login-form
git branch -d feature/login-form

# 2. releaseブランチで仕上げ、mainとdevelopへ戻す
git switch -c release/1.2.0 develop
# 版番号を更新してコミット
git switch main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git switch develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

# 3. hotfixブランチで本番の不具合を直し、mainとdevelopへ戻す
git switch -c hotfix/1.2.1 main
# 修正してコミット
git switch main
git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m "Hotfix 1.2.1"
git switch develop
git merge --no-ff hotfix/1.2.1
git branch -d hotfix/1.2.1
git push origin main develop --tags

原典が --no-ff を指定するのは、fast-forwardできる場合でも必ずマージコミットを作るためです。こうすると、あるfeatureブランチが存在したという事実が履歴に残り、その機能を構成するコミットがひとまとまりになります。fast-forwardで取り込むと、どのコミットが1つの機能だったのかをログから読み取れず、機能をまるごと取り消すのが「本当に頭の痛い作業」になると原典は書いています。--no-ff で残したマージコミットなら、git revert -m 1 で機能単位に取り消せます。取り消し方の使い分けはgit mergeの取り消し｜abort・reset・revert -mの使い分けで詳しく扱っています。

featureブランチをdevelopの最新に追従させる方法には、developをマージする方法とrebaseする方法があります。共有前の自分だけのfeatureブランチならrebaseで履歴を一直線にでき、pushした後に他人と共有しているならマージが安全です。rebaseの挙動はgit rebaseとは？使い方・mergeとの違いを参照してください。

git-flowツールの現状：オリジナル版とAVH版はアーカイブ済み

上の手順を git flow feature start のようなサブコマンドにまとめる拡張ツールが、git-flowです。ただし、原典の著者によるオリジナル版（nvie/gitflow）と、その後継として広く使われたAVH版（petervanderdoes/gitflow-avh）は、どちらもGitHub上でアーカイブ（読み取り専用）になっています。2026年9月時点で更新が続いているのは、GitクライアントTowerの開発元がGoで作り直したgit-flow-nextで、最新版はv2.1.0（2026年9月8日）です。

# git-flow-next（Homebrewの例。macOS・Linux共通）
brew install git-flow-next
git flow init
git flow feature start login-form
git flow feature finish login-form

git-flow-nextは従来のgit-flowやAVH版との後方互換をうたっています。古い解説記事にある brew install git-flow-avh は、AVH版のformulaが2026年3月5日にHomebrewから削除されたため、現在は実行しても失敗します。オリジナル版の git-flow formulaも2025年12月19日に非推奨となり、2026年12月19日に無効化される予定で、代替にはgit-flow-nextが指定されています。ツールは手順の省略に過ぎず、使わなくてもGit Flowは運用できます。

GitHubでdevelopを運用するときに既定ブランチで変わる3つの挙動

GitHubには「既定ブランチ（default branch）」の設定があります。GitHub Docsによると、既定ブランチはリポジトリを開いたときに表示され、cloneしたときに最初にチェックアウトされ、別の指定がなければ新しいプルリクエストのマージ先になるブランチです。新規リポジトリでは main が既定です。

Git Flowでは、developとmainのどちらを既定にするかで、次の3つの挙動が変わります。検索上位の解説記事では扱われていませんが、運用を始めてから気づくと手戻りが大きい点です。

Issueの自動クローズはデフォルトブランチへのマージでしか動かない

プルリクエストの本文に Closes #12 のようなキーワードを書くと、マージ時にIssueが自動で閉じます。GitHub Docsは、この連携が機能するのはプルリクエストが既定ブランチ宛ての場合だけだと明記しています。mainを既定にしたままfeatureをdevelop宛てのプルリクエストでマージすると、キーワードは無視され、Issueは開いたままです。

コミットメッセージに書いたキーワードは、そのコミットが既定ブランチにマージされた時点で効きます。mainが既定なら、releaseをmainへマージしたとき、つまり実際にリリースしたときにIssueが閉じる運用にできます。逆にdevelopを既定にすると、リリース前のdevelopへのマージでIssueが閉じるので、「閉じた＝本番に出た」ではなくなります。Issue運用の全体はGitHub Issueとは？使い方・書き方と運用のベストプラクティスにまとめています。

Dependabotの更新PRと、セキュリティ更新だけの例外

Dependabotは既定では既定ブランチの依存関係を調べ、既定ブランチ宛てに更新のプルリクエストを出します。mainが既定のままGit Flowを使うなら、dependabot.yml で target-branch を指定してdevelopへ向けます。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    target-branch: "develop"

ただし target-branch が効くのはバージョン更新だけです。GitHub Docsは「セキュリティ更新は常に既定ブランチを使う」としています。mainが既定なら、脆弱性修正のプルリクエストはmainへ直接届くので、hotfixと同じ扱いでdevelopにも取り込む手順を決めておく必要があります。

scheduleで動くワークフローは既定ブランチの定義だけが使われる

GitHub Actionsの on: schedule で起動するワークフローは、既定ブランチの最新コミットにあるワークフロー定義でしか動きません。developにだけナイトリービルドのワークフローを追加しても、mainが既定なら定期実行は始まりません。ブランチ別のトリガーの書き方はGitHub Actionsのトリガー（on）｜イベント選定とbranches・pathsフィルタの設計で解説しています。

判断の目安として、日々のプルリクエストの大半がdevelop宛てになるGit Flowでは、developを既定ブランチにするほうが設定の手間が少なく済みます。その場合は、Issueのクローズがリリースを意味しなくなる点を、マイルストーンやGitHub Releasesで補います。

developブランチを置かない選択：GitHub Flowや環境別ブランチとの違い

developは、どのチームにも必要なブランチではありません。原典の著者は2020年3月5日に記事の冒頭へ「Note of reflection」を追記し、Gitで開発されるソフトの主流がWebアプリに移ったと振り返っています。Webアプリは継続的にデリバリーされ、ロールバックもせず、複数バージョンを保守する必要もない。そうしたチームには、Git Flowを無理に当てはめるより、GitHub Flowのような単純なワークフローを勧めると書いています。一方で、明示的にバージョンを付けて出すソフトや、複数バージョンを並行して保守するソフトには、Git Flowが今も合うかもしれないとしています。AtlassianのGitチュートリアル（日本語版にも同じ記述があります）も、Gitflowを「レガシー Git ワークフロー」と位置づけ、現在の継続的な開発ではトランクベースの運用がベストプラクティスとされていると説明しています。

GitHub Flowは、既定ブランチから作業ブランチを切り、プルリクエストでレビューしてマージし、マージ後にブランチを削除するという流れです。developもreleaseもhotfixもなく、mainが常にデプロイ可能な状態を保ちます。GitLabのドキュメントは、testやUATのように環境ごとにブランチを置く方式を、相互に依存する複数のサービスを別々のチームが作る組織で一般的な方式として紹介しています。

developをやめるべきなのは、リリースが1日に何度もあり、releaseブランチを切る時点が存在しないチームです。developとmainの差分が常にほぼゼロなら、developは手順を増やしているだけです。逆に、アプリストアの審査を挟むモバイルアプリや、顧客ごとに版を出し分けるパッケージ製品では、developとreleaseで「次の版」と「今出す版」を分ける意味が残ります。未完成の機能をmainに入れたまま隠す方法としては、フィーチャートグル（機能フラグ）があります。チームに合う戦略の選び方とルールの決め方は、Git運用のベストプラクティス｜ブランチ戦略・コミット規約・レビュー基準の決め方で比較しています。

mainとmasterの違いとブランチ名を変更するコマンド

原典のmasterと、現在よく見るmainは同じ役割のブランチで、違うのは名前だけです。GitHubは新規リポジトリの既定ブランチ名を main にしています。Git本体も、次の互換性を壊すメジャー版（Git 3.0）で新規リポジトリの既定ブランチ名を main に変えると、公式の BreakingChanges 文書で予告しています。Git 3.0が出るまでは、init.defaultBranch の設定で変えられます。

既存のリポジトリでmasterをmainに変えるときは、先にGitHub上（ブランチ一覧で対象ブランチのメニューから「Rename branch」）で名前を変えます。手元で git branch -m してからpushすると、GitHub上には別のブランチとしてmainが増え、masterはそのまま残るためです。既定ブランチの名前を変えられるのはリポジトリの管理者です。

GitHub上で名前を変えると、古いブランチ名を含むURLが新しい名前へ自動でリダイレクトされ、ブランチ保護の設定や、開いているプルリクエストのマージ先も付け替わります。ただし、rawファイルのURLはリダイレクトされず、古い名前で git pull しても転送されません。GitHub Actionsのアクションを @master のようにブランチ名で参照している利用者の環境も壊れるので、アクションを公開しているリポジトリでは名前の変更を慎重に行ってください。各メンバーの手元は、GitHub Docsの手順どおり次のコマンドで追従させます。

# 新規リポジトリの既定ブランチ名をmainにする
git config --global init.defaultBranch main

# GitHub上で名前を変えた後、手元のブランチを追従させる
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

よくある質問

developブランチとは何ですか？

Git Flowで、次のリリースに入れる変更を集めておく統合ブランチです。featureブランチはdevelopから切ってdevelopへ戻し、リリースの準備が整ったらreleaseブランチを経由してmainへマージします。mainと同じく削除しない常設のブランチです。

featureブランチの意味と名前の付け方は？

featureは英語で「機能」という意味で、featureブランチは1つの機能や改修を開発するための作業用ブランチです。feature/login-form のように接頭辞と作業内容を組み合わせ、チケット番号を入れておくとIssueとの対応が分かりやすくなります。

releaseブランチとdevelopブランチの違いは？

developは次のリリースに向けて新機能を受け入れ続けるブランチで、releaseは版番号を決めた時点でdevelopから切り、仕上げだけを行うブランチです。releaseでは大きな新機能を追加せず、完成したらmainとdevelopの両方へマージして削除します。

hotfixブランチをdevelopにマージし忘れるとどうなりますか？

本番のmainには修正が入っても、developには入らないため、次のリリースで同じ不具合が再発します。hotfixの完了時はmainとdevelopの両方へのマージを1つの手順として扱い、releaseブランチが存在する間はdevelopの代わりにreleaseへマージします。

developブランチは必ず作る必要がありますか？

必要ありません。継続的にデプロイするWebサービスでは、mainと作業ブランチだけのGitHub Flowで足ります。developが役立つのは、版番号を付けてリリースするソフトや、複数のバージョンを並行して保守するソフトです。

関連記事

• ブランチとは？バージョン管理で開発を分岐させる仕組みと使い方を実装視点で解説
• Git運用のベストプラクティス｜ブランチ戦略・コミット規約・レビュー基準の決め方
• git rebaseとは？使い方・mergeとの違い・コンフリクト解決とやり直しを解説
• コンフリクトとは？Gitで変更が衝突する仕組みと解消手順・予防設計を実装視点で解説
• GitHub Issueとは？使い方・書き方と運用のベストプラクティス【2026年版】