午前2時14分のモーニングコール
携帯が震えるどころか、悲鳴を上げているようでした。PagerDutyのアラートが独立記念日のフィナーレのように鳴り響いています。主力ECプラットフォームでは、毎分1万5千人以上のユーザーが500エラーに直面し、流出が続いていました。私は目をこすりながらノートPCにかじりつき、デプロイログを確認しました。一見、ビルドは「成功（green）」していましたが、Gitの履歴が真犯人を物語っていました。
ジュニアデベロッパーが、ローカライズのホットフィックスをプッシュしようとして、誤って実験的なUIリファクタリングをmainブランチにマージしてしまったのです。私たちのCI/CDパイプラインはmainへのプッシュごとに自動デプロイされる設定だったため、壊れたコードが即座に本番環境に反映されてしまいました。その後180分間、マージコンフリクトの解消とデータベースマイグレーションの手動ロールバックに追われました。これはツールの失敗ではなく、ブランチ戦略の失敗でした。
ブランチモデルの選択は、単なる技術的な好みではなく、リスク管理の決断です。デプロイ頻度と戦略が一致していなければ、それはDevOpsを実践しているのではなく、単に混乱を自動化しているに過ぎません。
ブランチ戦略の3大勢力
次にgit checkout -bを実行する前に、ワークフローをビジネス目標に合わせる必要があります。ほとんどのチームは、次の3つのパターンのいずれかに当てはまります。
1. GitFlow：規律を重んじるベテラン
GitFlowは「重量級」のモデルと考えてください。構造化され、厳格で、リリースサイクルを最大限に制御できます。レガシーなエンタープライズソフトウェアや、App Storeに公開した後に簡単に「デプロイ取り消し」ができないモバイルアプリを管理しているチームに推奨します。
- Main & Develop: これらに直接コミットすることはありません。
Mainはクリーンな本番履歴、Developは統合用のサンドボックスです。 - Featureブランチ: 日々の開発作業を行う場所です。
- Releaseブランチ: 新機能の開発を止めることなく、次期バージョン（例：v2.1.0）のブラッシュアップを行うための専用スペースです。
- Hotfixブランチ: 本番環境のバグを即座に修正するために、標準のフローをバイパスできる唯一の手段です。
2. GitHub Flow：ミニマリストなスピードスター
GitHub Flowは、迅速かつ頻繁にリリースしたいSaaSチームにとっての定番です。「mainブランチにあるものは常にデプロイ可能である」という、シンプルで高い信頼に基づいた前提で動作します。1日に10回デプロイするようなスタートアップであれば、GitFlowは足かせにしかなりません。
- すべてのタスクにおいて、
mainからブランチを切る。 - 議論を始めるために、早い段階でPull Request (PR)を作成する。
- PRがCIテストとピアレビューを通過したら、マージする。
- マージ後、直ちに本番環境へデプロイする。
3. GitLab Flow：環境優先の中間モデル
GitLab Flowは、環境ブランチを導入することで、GitHub Flowの「シンプルすぎる」という問題を解決します。これは、厳格なQA要件や規制上のハードルがある組織にとっての救世主です。mainが本番であると仮定するのではなく、コードは一連のゲートを通過していきます。
例えば、main（ステージング）、pre-productionブランチ、そしてproductionブランチを持つことができます。機能は、すべての環境を順にマージして上がっていくまで「完了」とはみなされません。これにより、「自分の環境では動いた」というバグが有料顧客に届くのを防ぐことができます。
理論を実践に移す
危機的状況において、これらのワークフローがターミナルで実際にどのように動作するかを見てみましょう。チームの半分が大規模なAPI刷新の真っ最中に、セッションタイムアウトのバグを修正する必要がある場面を想定してください。
シナリオA：GitFlowでのホットフィックス
GitFlowでは、修正を「混乱した」開発ブランチから分離します。本番環境の状態から直接ブランチを作成します。
# 本番環境のコードを隔離
git checkout main
# 緊急対応用の専用ブランチを作成
git checkout -b hotfix/fix-session-timeout
# 修正を適用
git commit -am "修正：セッションタイムアウトのロジックを修正"
# mainにマージし、記録のためにタグを打つ
git checkout main
git merge hotfix/fix-session-timeout
git tag -a v1.1.4 -m "重大なセキュリティパッチ"
# 重要なステップ：修正内容を開発チームに同期する
git checkout develop
git merge hotfix/fix-session-timeoutシナリオB：GitHub Flowでの機能開発
GitHub Flowでは、プロセスは無駄がありません。’develop’か’main’かを気にする必要はなく、目の前の機能に集中するだけです。
# 常に最新の本番コードから開始
git checkout main
git pull origin main
# Stripeの新しい連携作業を開始
git checkout -b feature/stripe-payments
git commit -m "機能：チェックアウト用のStripe APIを統合"
# プッシュしてCIパイプラインに重労働を任せる
git push origin feature/stripe-payments
# 承認後、マージして自動デプロイをトリガー
git checkout main
git merge feature/stripe-payments
git push origin mainCI/CDパイプラインの最適化
よくある間違いは、すべてのコミットに対して全テストスイートを実行してしまうことです。これはリソースの大きな無駄です。CIの設定をブランチ戦略に合わせることで、ビルド時間とクラウドコストを大幅に削減できます。
最近のプロジェクトでは、GitHub Flow의 パイプラインを絞り込み、mainへのPRに対してのみ重い統合テストを実行するようにしました。これにより、AWS CodeBuildの費用が35%削減され、開発者のフィードバックループが22分から6分に短縮されました。パイプラインはスマートであるべきです。Featureブランチではユニットテストを実行し、高コストなエンドツーエンド（E2E）テストはマージ候補のために取っておきましょう。
どれを選ぶべきか？
図に描いたときに「プロっぽく見える」からという理由で戦略を選ぶのはやめましょう。自分自身に次の3つの厳しい問いを投げかけてみてください。
- デプロイを数秒でロールバックできますか？ はい、ならGitHub Flowを使いましょう。ロールバックに20分かかるなら、より多くのゲートが必要です。
- ソフトウェアに「バージョン」はありますか？ v1.2とv2.0を異なるクライアントに同時に提供する場合、GitFlowが唯一の現実的な選択肢です。
- リリースの承認に人の手が必要ですか？ QAチームがビルドの手動テストに48時間を要する場合、環境ブランチを用いたGitLab Flowを使用してください。
スタートアップの5人程度の小規模チームにとって、GitFlowは過剰（オーバーキル）です。勢いを削ぐ不要なマージのオーバーヘッドが発生します。安全要件を満たす最もシンプルなモデルから始め、本番障害の痛みがプロセスの痛みを上回ったときに初めて、複雑さを追加してください。
最後に
Gitのブランチ管理は、単にフォルダを整理することではありません。チームが価値を届けるための設計図です。午前2時の悪夢が起きたのは、「実験的」なコードと「本番準備完了」のコードের 境界線が不明確だったからです。稼働率を運任せにしないでください。今日、CONTRIBUTING.mdファイルに戦略を文書化しましょう。あなたの睡眠スケジュール、そして顧客が感謝することでしょう。
