Hotfix Branch: モバイル開発での作成と適用方法

Hotfix Branchとは？

Hotfix Branchは、稼働中の本番環境における重大な欠陥を迅速に修正するために作成されるGitの一時的なブランチです。developから分岐して数日または数週間存続するfeatureブランチとは異なり、hotfixはmain/masterから作成され、バグ修正に必要な期間だけ存在します。

hotfixの主な目的は、重大なエラーの発見から本番環境での修正までの時間を最小化することです。チームは現在のスプリントやリリースサイクルの終了を待たず、即座にパッチをリリースします。これは、重大なバグがユーザーをブロックし、離脱につながる可能性があるモバイルアプリケーションで特に重要です。

Google Play Consoleによると、Google Playでのアップデート審査の平均時間は2〜24時間です。App Storeの場合、迅速審査は1〜4時間かかることがあります。Hotfixブランチを使用すると、審査が完了する前に修正を準備し、承認後すぐにリリースできます。

Hotfixの仕組み

Hotfixプロセスは3つのステップで構成されます：mainからブランチを作成し、修正を加え、mainとdevelopにマージします。通常の修正との主な違いは、hotfixは常に両方のブランチにマージされるため、次のリリースで修正が失われないことです。

チームはhotfixに新機能やリファクタリングを導入すべきではありません。重大な問題を解決するために最小限必要な、的を絞った修正のみを行います。このルールから逸脱すると、リグレッションのリスクが高まり、パッチのリリースが遅れます。

Hotfixが必要なケース

Hotfixは3つのシナリオで必要です：重大なバグがユーザーをブロックする場合（クラッシュ、データ損失）、セキュリティ脆弱性を直ちに塞ぐ必要がある場合、または重要なビジネスロジック（決済、認証）が壊れている場合。バグが重大でなければ、developを通じて通常のリリースサイクル内で修正できます。

モバイルアプリケーションの場合、アーキテクチャがリモートでの機能切り替え（feature flags）を許可していれば、hotfixにはサーバー側の変更も含めることができます。この場合、修正がサーバー側で行えるなら、hotfixブランチは最小限で済むか、まったく不要になることもあります。

ブランチモデルとHotfixの位置づけ

すべてのブランチモデルがhotfixブランチをサポートしているわけではありません。伝統的なGit Flowはhotfixを完全なブランチタイプとして含んでいますが、より現代的なアプローチ（GitHub Flow、Trunk-based）は緊急修正を別の方法で扱います。

Git FlowとHotfix

Git Flowは、featureやreleaseと同様にhotfixが組み込みのブランチタイプとなっている唯一のモデルです。Git Flowでは、hotfixはmainから作成され、完了後にmain（バージョンタグ付き）とdevelopの両方にマージされます。これにより、次のリリースで修正が失われないことが保証されます。

GitHub FlowとTrunk-based

GitHub Flowはhotfixに別個のブランチタイプを使用しません。代わりに、開発者はmainから通常のfeatureブランチを作成し、修正を加えてPull Requestを開きます。レビューとCIチェックの後、ブランチはmainにマージされて即座にデプロイされます。利点はシンプルさであり、欠点は緊急修正のための専用チャネルがないことです。

Trunk-based開発では、hotfixを（重大なケースでは）mainへの直接コミットで処理し、事後レビューを義務付けます。このアプローチには、高いチーム規律と信頼性の高い自動テストが必要です。変更が即座に本番環境に反映されるためです。

Hotfix Branchの作成方法

Hotfixの作成は、メインブランチに切り替えてhotfix/プレフィックス付きの新しいブランチを作成することから始まります。モバイルアプリケーションの重大なバグ修正を例に、ステップバイステップのプロセスを見ていきましょう。

mainからブランチを作成

最初のステップ — mainに切り替え、ブランチが最新であることを確認します。次に、修正の性質を反映した明確な名前のhotfixブランチを作成します。

# mainに切り替えて最新の変更を取得
git checkout main
git pull origin main

# hotfixブランチを作成
git checkout -b hotfix/crash-on-login

ブランチを作成したら、修正を行います。重要なのは、hotfixには最小限の変更のみを含めることです。コードのリファクタリングや新機能の追加は行わず、問題を解決するための的を絞った修正のみを行います。

修正のコミット

hotfixのコミットメッセージは、問題とその解決策を明確に説明する情報提供型である必要があります。形式：タイプ(領域): 簡潔な説明 + トラッカーのタスクへのリンク。

# 変更したファイルを追加
git add src/ui/login/LoginActivity.kt

# 説明付きでコミットを作成
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

コミットメッセージには問題の説明とタスクへのリンクを含める必要があります。これにより、履歴の検索が容易になり、同僚が何をなぜ修正したかを理解するのに役立ちます。モバイルプロジェクトでは、バグが見つかったアプリケーションバージョンも記載するのが一般的です。

mainとdevelopへのマージ

最終ステップは、hotfixをmain（新しいパッチバージョンタグ付き）とdevelop（次のリリースで修正を保持するため）にマージすることです。最初にmainにタグ付きでマージし、次にdevelopにマージします。

# mainにマージしてタグを作成
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# developにマージ
git checkout develop
git merge --no-ff hotfix/crash-on-login

# 変更をサーバーにプッシュ
git push origin main --tags
git push origin develop

--no-ffフラグは、fast-forwardでhotfixを適用できた場合でも、マージコミットの作成を保証します。これにより、緊急修正が行われたという情報が保持され、将来の履歴分析が容易になります。

Hotfix、Feature、Releaseブランチの違い

Hotfixは、目的、存続期間、マージルールの点でfeatureブランチやreleaseブランチとは根本的に異なります。これらの違いを理解することは、チームでGitプロセスを適切に組織するために重要です。

Featureブランチは新機能のためのものです。数日から数週間存続し、developから作成されてdevelopにマージされます。featureには多数のコミットが含まれることがあり、実験的なものも含まれ、後でsquashやrebaseで圧縮されます。

Releaseブランチはリリースをデプロイ用に準備します。developから作成され、安定化中に発見されたバグが修正され、新機能は受け入れません。完了後、releaseはmain（タグ付き）とdevelopにマージされます。

Hotfixは、一方で、developをバイパスしてmainと直接作成およびマージされます（ただし、修正後はdevelopとも同期されます）。最小限の変更を含み、最小限の時間だけ存在します。featureやreleaseブランチは次のサイクルまで延期できますが、hotfixは延期できません。

モバイル開発では、この区別が特に重要です。App StoreとGoogle Playでは、メジャーリリースとは別にパッチバージョンをリリースできます。hotfixブランチにより、パッチリリースが未完了の機能と混ざらないことが保証されます。

Hotfix作業でのよくある間違い

hotfix作業での間違いは、緊急修正の利点を台無しにする可能性があります。Git Flowを使用するチームで発生する最も一般的な5つの問題を見てみましょう。

• developからhotfixを作成する — developからhotfixを作成すると、未完了の機能がパッチに含まれる可能性があります。hotfixはmainからのみ作成し、修正には安定したコードのみが含まれるようにする必要があります。
• 1つのhotfixに複数の修正を含める — 各修正は個別のhotfixブランチにすべきです。1つのブランチに複数のバグを混在させると、コードレビューが複雑になり、リグレッションのリスクが高まり、必要な場合のロールバックが困難になります。
• developへのマージを省略する — hotfixをdevelopにマージしないと、次のリリースで修正が失われます。チームは同じバグが再発したことに気づき、再度修正する必要があります。
• 不正なバージョンタグ — hotfixはパッチインクリメント（v2.3.0 → v2.3.1）を受けるべきであり、マイナー（v2.4.0）やメジャー（v3.0.0）ではありません。セマンティックバージョニングに違反すると、ビルドシステムが壊れ、ユーザーを混乱させます。
• CIチェックの欠如 — 緊急hotfixでも自動テストをパスする必要があります。CIをスキップすると、新たなエラーを導入するリスクが高まります。hotfixブランチには、迅速なチェックを行う個別のパイプラインを用意することをお勧めします。

これらの間違いはそれぞれ、パッチリリースの遅延や本番環境での新たな問題の発生につながります。チームはCONTRIBUTING.mdにhotfixの作業ルールを文書化し、CI/CDチェックを通じて自動化する必要があります。