GitのRelease Branch — その概要、目的、ワークフロー

GitのRelease Branchとは

Release Branch（リリースブランチ）は、チームが現在の機能セットがリリース可能と判断したときにdevelopから作成されるGit Flowの一時的なブランチです。その存続期間は最終リリース準備にかかる時間と正確に一致し、数時間から数日間です。

リリースブランチの主な目的は、次バージョンの開発を止めずに、特定の機能セットをリリース用に固定することです。リリースブランチがデプロイメントの準備をしている間、他の開発者は次回リリースに向けてdevelopへのフィーチャーブランチのマージを続けることができます。

リリースブランチでは新機能は作成されません。バグ修正、アプリケーションバージョンの更新、ローカライゼーション、ドキュメントのみが行われます。すべての作業が完了すると、リリースブランチはmain（リリースとしてマーク）とdevelop（バグ修正が将来のバージョンに反映されるため）にマージされます。

Atlassian（2024年）によると、リリースブランチは定期的なリリースサイクルを持つプロジェクトにとって極めて重要であり、リリースプロセスの予測可能性と安定性を保証します。

リリースブランチのライフサイクル

リリースブランチのライフサイクルは、作成から削除まで複数の段階を含みます。各段階を理解することで、チームは行動を同期し、ミスを回避できます。

1. 作成 — developの最新コミットからrelease/2.5.0という名前のブランチが作成されます。developは次バージョンのフィーチャーブランチを引き続き受け入れます。
2. 準備 — リリースブランチでbuild.gradle、Info.plist、その他の設定ファイルのアプリケーションバージョンが更新されます。
3. バグ修正 — 最終テスト中に見つかった重大なエラーが修正されます。バグのみで、新機能はありません。
4. 最終テスト — QAチームがリリースブランチで回帰テストを実施します。新しいバグは同じブランチで修正のために送られます。
5. mainへのマージ — リリースブランチは--no-ffフラグ付きでmainにマージされます。リリースタグが作成されます：v2.5.0。
6. developへのマージ — リリースブランチはdevelopにマージバックされ、リリースのバグ修正が現在の開発に反映されます。
7. 削除 — リリースブランチはタスク完了後、ローカルおよびリモートで削除されます。

ステップ6（developへのマージバック）はしばしば忘れられますが、極めて重要です。これがないと、リリースで行われたバグ修正がdevelopに反映されず、次回リリースで同じエラーが再発する可能性があります。

リリースブランチの各段階の典型的な期間

リリースブランチの存続期間は、リリースの複雑さとdevelopのコード品質に依存します。中規模のモバイルアプリケーションの場合、準備には平均2〜5営業日かかります。

リリースブランチで行われる作業

リリースブランチでは、厳密に制限されたタスクセットのみが実行されます。このリストから逸脱するとGit Flowモデルに違反し、リリースの安定性にリスクをもたらします。

新機能禁止のルールはリリースブランチで最も重要です。機能がリリースに間に合わなかった場合、次のサイクルを待ちます。未完成の機能をリリースブランチに押し込もうとすることは、納期遅延と本番バグの主な原因です。

モバイルプロジェクトでのバージョン更新

リリースブランチでは、アプリケーションバージョン番号が必須で更新されます。Androidの場合はbuild.gradleのversionCodeとversionNameフィールド、iOSの場合はInfo.plistのCFBundleShortVersionStringです。

// build.gradle（アプリレベル） — リリースブランチでのバージョン更新
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// iOSの場合 — Info.plistの更新
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Releaseとhotfixの違い

初心者の開発者はreleaseとhotfixブランチを混同することがよくありますが、それらの目的は根本的に異なります。誤ったブランチタイプを選択すると、重要な修正が遅れたり、リリースプロセスが中断されたりする可能性があります。

• ソース — releaseはdevelopから作成され、hotfixはmainから作成されます。これが他のすべてを決定する主な違いです。
• 緊急性 — releaseは計画的で、チームが準備開始時期を決定します。Hotfixは緊急で、本番の問題を即座に修正する必要があります。
• 内容 — releaseには複数の修正とバージョン更新が含まれます。Hotfixには1つの重大な修正のみが含まれます。
• マージ — releaseはmainとdevelopにマージされます。Hotfixもmainとdevelopにマージされますが、優先的に行われます。
• 存続期間 — releaseは1〜7日間存続します。Hotfixは30分〜1日間存続します。

リリース準備中（リリースブランチ内）にバグが見つかった場合、それは通常のバグ修正です。本番環境（main上）でバグが見つかった場合、それはhotfixであり、リリースブランチが既に存在していてもmainから作成されます。

リリースブランチの命名規則

統一されたリリースブランチの命名標準により、リポジトリのナビゲーションが簡素化され、CI/CDシステムがブランチがリリースプロセスに属することを自動的に検出できるようになります。

• release/X.Y.Z — 標準のGit Flow形式。X.Y.Zはリリースバージョンです。例：release/2.5.0。
• release/名前 — リリースコードネームを使用する代替形式。例：release/merlin。
• release/日付 — リリース日付を使用する形式。バージョンの方が日付より重要であるため、あまり使用されません。例：release/2024-12-01。

release/X.Y.Z形式が推奨されます。ブランチをリリースに割り当てられるバージョン番号に明示的に関連付けるためです。これにより、CI/CDスクリプトによる検索と自動処理が簡素化されます。

developへのマージバック戦略

リリースブランチのdevelopへのマージバックは、最も重要でありながら最も頻繁にスキップされる操作の1つです。これがないと、リリースブランチで行われたすべてのバグ修正はリリースバージョンにのみ残り、次のリリースサイクルに反映されません。

マージバックプロセスは、リリースブランチがmainにマージされた後に実行されます。最初にreleaseがdevelopにマージされ、次に削除されます。これにより、developにリリース準備中に行われたすべての修正が含まれることが保証されます。

マージバック後、特に同じファイルを変更した新しいフィーチャーブランチが既にdevelopに出現している場合、競合が発生する可能性があります。リリース責任者の開発者がこれらの競合を解決し、developをサーバーにプッシュします。

一部のチームは、履歴を線形に保つために、マージバックにマージではなくリベースを使用します。ただし、マージはdevelopにとってより安全であり、他の開発者が既に使用しているコミット履歴を書き換えないためです。

リリース作業のコマンド例

モバイルアプリケーションバージョン2.5.0のリリース成功後のリリースブランチの全サイクル（作成から削除まで）を見てみましょう。

# 1. developからリリースブランチを作成
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. バージョンとバグ修正を更新
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. バグを修正（バグ修正のみ）
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. リリースブランチをサーバーにプッシュ
git push origin release/2.5.0

# 5. releaseをmainにマージ
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. developにマージバック
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. リリースブランチを削除
git branch -d release/2.5.0
git push origin --delete release/2.5.0

コマンド5と6（二重マージ）は極めて重要です。最初にmainがリリースコードとタグを受け取り、次にdevelopがリリースのバグ修正と同期します。ステップ6をスキップすると、リリースの修正が次の開発サイクルに反映されません。

リリースプロセスの自動化

定期リリースのあるモバイルプロジェクトでは、リリースブランチの作成とバージョン更新のプロセスをCI/CDスクリプトで自動化できます。GitHub Actionsを使用すると、ボタンをクリックするだけで自動バージョン更新付きのリリースブランチを作成するワークフローを構築できます。

定期リリースのあるモバイルプロジェクトでは、リリースブランチの作成とバージョン更新のプロセスをCI/CDスクリプトで自動化できます。GitHub Actionsを使用すると、ボタンをクリックするだけで自動バージョン更新付きのリリースブランチを作成するワークフローを構築できます。

# GitHub Actions — リリースブランチ作成の自動化
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}