開発プロセスなしのチーム作業は「崩壊」を招く
働き始めたばかりの頃、Gitは add、commit、push さえできれば十分だと思っていました。しかし、プロジェクトが10人以上に拡大し、全員がショッピングカートのロジックを修正して直接 master にプッシュし始めた途端、状況は一変しました。結果として、膨大なコンフリクトが発生し、自分のローカル環境では動いても本番環境（Production）ではファイル不足でエラーになるという事態に。Git Flowは、こうした混乱を収拾し、開発中のコードと本番用コードの間に「鋼の境界線」を引くために誕生しました。
クイックスタート：5分でGit Flowを導入する
分厚いドキュメントを読むのに時間を費やす必要はありません。まずは git-flow ツールをインストールしましょう。これは、4〜5つのGitコマンドを打つ代わりに、短いキーワードで複雑なプロセスを実行できるようにする「ショートカット（ラッパー）」のようなものです。
1. クイックインストール
# macOS
brew install git-flow-avh
# Ubuntu/Debian
sudo apt-get install git-flow
# Windows
# 通常、Git Bashに標準搭載されています。もし入っていない場合はgit-flow-avhをダウンロードしてください。2. プロジェクトの初期化
プロジェクトのルートディレクトリでターミナルを開き、以下を入力します：
git flow initこの時、Gitが各ブランチ名（main, develop, feature…）を尋ねてきます。私のアドバイスは、すべてEnterキーを押してデフォルト設定にすることです。そうすることで、チームメンバーや海外のパートナーともスムーズに連携できます。
3. 新機能の開発を開始する
git flow feature start login-facebookこのコマンドにより、develop から自動的に新しいブランチが作成され、そのブランチに切り替わります。コードを書き終えたら、以下を入力するだけです：
git flow feature finish login-facebookこれにより、自動的に develop へマージされ、作成したブランチも削除されます。非常に手間いらずです！
Git Flowの「根幹」をなす5種類のブランチを解明する
このワークフローでは、リポジトリを永続的な2つのメインブランチと、役割が終われば削除される3つのサポートブランチに分けます。
1. メインブランチ (Main & Develop)
- Main: 厳格なテストをパスした最もクリーンなコード。顧客にリリースする準備が整った時のみ、ここにコードを反映します。Mainに直接
commitすることは絶対に避けてください。 - Develop: いわば「実験室」です。すべての新機能はここに集約され、パッケージ化する前にメンバー間で相互テストを行います。
2. サポートブランチ (Feature, Release, Hotfix)
- Feature: Jira上の各タスクは独立したブランチにするべきです。不変のルール：1タスク = 1ブランチ。
- Release: developブランチにバージョン2.0用の機能が十分に蓄積されたら、このブランチを切り出します。この段階はUIの軽微な修正やタイポの修正のみを行い、新しい機能の追加は絶対に行いません。
- Hotfix: 大晦日の夜に決済ページで500エラーが発生したと想像してください。この場合、
mainからHotfixブランチを切り出し、修正後にmainとdevelopの両方にマージして、即座に「火消し」を行います。
応用編：Git Flowとプルリクエスト (PR) の連携
大企業の実際の開発現場では、個人のPCで finish コマンドを使うことは稀です。代わりに、GitHubやGitLab上でのコードレビュープロセスと組み合わせます：
git flow feature start 自分のタスクでブランチを作成。- ブランチをサーバーにプッシュ：
git push origin feature/自分のタスク。 - ウェブ上で Pull Request を作成し、同僚にコードをレビューしてもらいます。
- 承認（Approve）されたらウェブ上でマージし、ローカル環境で
pullして最新コードを取り込みます。
生存のヒント：なぜ –no-ff を使うべきなのか？
--no-ff（no fast-forward）フラグなしで手動マージすると、Gitは複数のコミットを一本の直線にまとめてしまいます。これではリポジトリの履歴が非常に見づらくなります。--no-ff を使うことで、Gitは明確なマージコミット（結節点）を作成します。図で見ればその機能がどこで始まりどこで終わったかが一目瞭然になり、後でバグが発生した際の追跡が非常に容易になります。
チームリーダーのための実践的アドバイス
Git Flowが負担にならないよう、チームに以下の3つのルールを適用しましょう：
1. チケットIDに基づいたブランチ命名
feature/fix-bug-gap（急ぎのバグ修正）のような曖昧な名前は避けましょう。ブランチ種別/チケット番号-概要 というフォーマットを使います。例：feature/PROJ-123-api-login や hotfix/PROJ-456-fix-crash-ios。
2. パイプラインの自動化 (CI/CD)
develop にコードがプッシュされたら、自動的に パイプラインの自動化 (CI/CD) 境にデプロイしてテスターが確認できるように設定しましょう。main にマージされ Tag v1.1 が付与されたら、自動的に Production に反映されるようにします。これにより、手動操作による初歩的なミスを90%削減できます。
3. 定期的なクリーンアップ
古いブランチを放置する癖がある人が多いですが、各スプリント（通常2週間）の終わりに5分時間を取って、マージ済みのブランチを削除しましょう。PCの動作が軽くなり、コードを探す際の手間も省けます。
おわりに
私は以前、巨大な新機能を開発している最中に、本番環境でのデータ消失バグの至急対応を上司から求められたことがあります。Git Flowを遵守していたおかげで、作業中のコードを stash し、main からHotfixブランチを作成して修正・デプロイするまでを、わずか15分で完了できました。すべてが非常にスムーズに進みました。
一人でプロジェクトを進める場合、Git Flowは少し冗長に感じるかもしれません。しかし、2人以上のチームであれば、初日からこのプロセスを導入することで、コンフリクト解消や「誰が誰のコードを上書きしたか」という不毛な議論に費やす時間を大幅に節約できます。
まずは恐れずに試してみてください。実際のプロジェクトに導入する前に、テスト用のリポジトリを作成して、init、start、finish コマンドを数回練習して手に馴染ませておくことをお勧めします！
