Gitにおける「fixブランチ」と「hotfixブランチ」の違いと活用法

はじめに

Gitの開発フローでは、新機能はfeatureブランチで進めますが、

「バグ修正」は状況に応じて fixブランチ または hotfixブランチ を使います。

どちらも「問題を直す」ためのブランチですが、使い分けることで開発効率と品質が大きく変わります。

1. fixブランチとは？

  • 開発中のバグ修正を行うブランチ
  • 基本的に developブランチやfeatureブランチから派生する
  • 本番環境にはまだ影響しない問題を直すのが目的

例

  • 開発中のUI表示崩れ
  • まだリリースしていない機能内での動作不具合
  • テスト段階で発見された軽微なバグ

命名例

fix/login-validation
fix/profile-image-upload

2. hotfixブランチとは？

  • 本番リリース済みコードに緊急対応するためのブランチ
  • 基本的に mainブランチから直接派生する
  • すぐにユーザー影響が出る不具合を直し、最優先でデプロイするのが目的

例

  • 本番でログインできない重大バグ
  • 課金処理が失敗する不具合
  • セキュリティ脆弱性の修正

命名例

hotfix/payment-crash
hotfix/security-patch

3. fix と hotfix の違いを整理

項目fixブランチhotfixブランチ
基点develop または featuremain
対象開発中の不具合本番稼働中の不具合
優先度通常最優先・緊急
リリース次回のリリースに含まれる即時リリース
命名例fix/◯◯hotfix/◯◯

4. 実際の運用フロー

fixブランチの流れ

  1. develop から派生
git checkout develop
git pull origin develop
git checkout -b fix/profile-image-upload
  1. 修正作業
  2. develop にマージ → テスト後、次回リリースに反映

hotfixブランチの流れ

  1. main から派生
git checkout main
git pull origin main
git checkout -b hotfix/payment-crash
  1. 修正作業
  2. main にマージ → 即リリース
  3. さらに develop にも反映（mainと開発の差分をなくすため）

5. 運用のポイント

  • hotfixは必ずmainとdevelop両方に反映→ そうしないと開発ブランチに修正が取り込まれず、再びバグが戻ってしまう
  • fixは慌てなくてよいが、hotfixは即対応が必須→ チーム全員が「何をhotfixと判断するか」を共有しておくと混乱が減る
  • 命名規則を統一→ fix/◯◯ と hotfix/◯◯ を明確に使い分けると、ブランチ名だけで優先度が伝わる

まとめ

  • fixブランチ：開発中の不具合を直す。develop基点。通常対応。
  • hotfixブランチ：本番に出てしまった不具合を直す。main基点。緊急対応。
  • 両者の使い分けを徹底することで、mainの安定性を保ちつつ迅速な対応が可能になります。
訪問数 5 回, 今日の訪問数 1回

Git,バージョン管理,便利機能

Posted by hidepon