← Back to Home

今更聞けない：チーム開発で絶対に破綻しないGitブランチ戦略の基本

#Git#GitHub#Teamwork#Engineering

個人開発でWebアプリを作っているうちは、「とりあえず git add . して git commit -m "update" して git push origin main すればOK！」という認識でも、何とかなってしまうことが多いです。

しかし、いざ企業に就職したり、複数人のエンジニアでチーム開発を行うようになると、この「mainブランチ直コミット」は絶対に許されない大罪へと変わります。 本番環境（ユーザーが実際に見ているサイト）のコードが壊れてしまうリスクが非常に高いためです。

この記事では、チーム開発において「誰が、どこで、どうやってコードを変更していくか」というルールの根幹である 「Gitのブランチ戦略」 について、最もポピュラーな2つの手法とその選び方を解説します。

Gitのブランチ戦略の概念図

1. 原則：「mainブランチ」は神聖にして不可侵

すべてのブランチ戦略に共通する絶対のルールが1つあります。 それは、**「main（旧 master）ブランチには、常に『今すぐ本番環境に出しても絶対にバグがおきない、完璧に動くコード』だけを置いておく」**ということです。

そのため、新しい機能（例えば「ログイン画面」）を作りたい時は、決してmainブランチを直接いじってはいけません。必ず main から枝分かれ（ブランチを切る）させ、自分専用の作業スペースである feature/login のような新しいブランチを作ります。

そこで試行錯誤しながらコードを書き、完成したら main に対して「私のコードを混ぜてください（マージしてください）」という申請（Pull Request : プルリクエスト）を出します。他のメンバーのコードレビュー（チェック）を受けて、初めて main に反映されるのです。

2. GitHub Flow：シンプル・イズ・ベストの王道

現在、多くのWebベンチャー企業やアジャイル開発の現場で採用されているのが 「GitHub Flow（ギットハブ・フロー）」 と呼ばれる戦略です。 名前の通り、GitHub社が提唱した非常にシンプルでスピーディな運用ルールです。

GitHub Flowの基本ルール

  1. mainブランチは常にデプロイ可能であること。
  2. 何か新しい作業を始める時は、目的に応じて「わかりやすい名前（例: add-user-login, fix-header-bug）」で、mainからブランチを切る。
  3. ローカル（自分のPC）でコミットしたら、サーバー（GitHub）上の同じ名前のブランチに定期的にPushする。
  4. 作業が終わったら、または途中で相談したい場合は、**Pull Request（PR）**を開く。
  5. 他のメンバーにコードレビューしてもらい、LGTM（Logks Good To Me: 承認）が出たら、mainにマージする。
  6. マージされたら、即座に本番環境へデプロイ（公開）する。

この戦略の最大のメリットは「シンプルであること」です。ブランチの種類が main と 作業用ブランチ の2つしかないため、初心者でも迷うことがなく、1日に何度も細かく本番環境をアップデートしていくようなモダンな開発スタイルに最適です。

3. Git-flow：厳密で堅牢な伝統的スタイル

一方で、月に1回決まった日にち（例えば毎月15日）に大規模なアップデートを行うような、より伝統的で厳格な開発現場（例えばスマホアプリの開発や、金融系のシステムなど）で採用されるのが 「git-flow（ギットフロー）」 です。

GitHub Flowが非常にシンプルなのに対し、git-flowは「5種類」のブランチを使い分けます。

5つの主要なブランチ

  • main: （リリース済みの）本番環境のコード。
  • develop: 【開発用】この戦略における「実質的な中心」。すべての新機能はこのdevelopに向けて合流していく。
  • feature/...: 【機能追加用】developから枝分かれし、機能が完成したらdevelopに戻る。
  • release/...: 【リリース準備用】developから枝分かれする。「明日リリースするぞ」という段階になったらこのブランチを作り、バグ修正やバージョン番号の変更だけを行う。完成したらmainとdevelopの両方にマージする。
  • hotfix/...: 【緊急修正用】本番（main）で致命的なバグが見つかった時だけ、mainから直接枝分かれし、修正後に即座にmainとdevelopにマージする。

非常に複雑に見えますが、メリットは**「開発中のコード（develop）」と「今すぐリリースできるコード（main/release）」が完全に分離されている**ため、複数の巨大な機能を何人のチームで並行して作っていても、リリース直前にパニックになりにくいという点です。

4. コンフリクト（衝突）で泣かないための3つの教訓

ブランチを切って作業していると、ある日突然、PRをマージしようとした時に真っ赤なエラー画面が出ることがあります。「コンフリクト（競合）」です。 「あなたが編集したファイルの全く同じ行を、数時間前にAさんも編集して先にmainにマージしちゃってるよ！どっちが正しいか教えて！」という、Gitからの悲鳴です。

これを最小限に抑え、泣きながらコードを直す羽目にならないための教訓は以下の3つです。

① ブランチ＝タスクの粒度を極限まで小さくする

1つのブランチで「ログイン機能も、プロフィール画面も、一緒に見た目も直しちゃおう」と欲張るのは最悪のアンチパターンです。 変更するファイルや行数が多ければ多いほど、他人のコードとぶつかる確率は指数関数的に跳ね上がります。ブランチは「1つの明確な目的」のためだけ切り、数時間〜長くても2,3日でマージできるサイズ感を保ちましょう。

② こまめに「最新のmain」を取り込む（rebase / merge）

自分が作業用ブランチにこもってコードを書いている数日間の間にも、他のメンバーが完成させた機能が次々とmainにマージされていきます。 1日1回は、自分の手元のブランチに最新のmainの情報を取り込み（git pull origin main または git fetch してからの git merge main）、自分のコードと衝突していないかを「こまめに」確認する癖をつけましょう。

③ コミュニケーションはGit以上に重要

システム側でどれだけ素晴らしいブランチ戦略を敷いても、「あ、そこの共通コンポーネント、今僕の方で直してますよ！」という開発者同士の雑談やSlackでの共有がなければ、コンフリクトは防げません。 「誰がどこを触っているか」というメタ認知をチーム全体で持つことこそが、最強のブランチ戦略と言えるかもしれません。