Gitブランチ戦略の基本
チーム開発の進め方

複数人で開発すると「誰がどこを直しているのか」が絡み合い、コンフリクトの温床になります。ブランチ戦略は、その混乱を防ぐための「作業の分け方のルール」です。代表的な戦略とその選び方を整理しました。

なぜブランチ戦略が必要なのか

全員が同じ main に直接コミットすると、未完成のコードが混ざり、リリースできる状態を保てなくなります。作業ごとにブランチを切り、レビューを通してから統合する——このルールを揃えることで、安全に並行開発ができます。

基本の役割：mainとfeature

どの戦略でも土台は同じです。まず「常に動く状態を保つ本流」と「作業用の枝」を分けます。

• main … いつでもリリースできる安定版
• feature/* … 機能追加や修正の作業用ブランチ

# 新しい作業ブランチを切る
git switch -c feature/login-form

# 作業してコミット後、mainへ取り込む準備
git push origin feature/login-form

GitHub Flow：シンプルで実務向き

小〜中規模やWebサービスで広く使われる、覚えやすい戦略です。

1. main から feature ブランチを切る
2. 作業してプッシュし、プルリクエストを作る
3. レビューとCIが通ったら main にマージ
4. すぐデプロイ

ブランチが少なくシンプルなので、まず最初に採用するならこれがおすすめです。

Git Flow：リリース管理が厳密な現場向き

develop・release・hotfix など役割ブランチが増える戦略です。バージョン管理が厳密なパッケージ製品などに向きますが、Webサービスにはやや重いこともあります。

ブランチ	役割
main	本番リリース済みの状態
develop	次リリースへ向けた統合先
feature/*	個別機能の作業
release/*	リリース準備・最終調整
hotfix/*	本番の緊急修正

ブランチ命名のコツ

名前を見ただけで用途が分かるよう、接頭辞を付けて揃えます。

• feature/user-search … 機能追加
• fix/login-error … バグ修正
• hotfix/payment-500 … 緊急対応

チケット番号を入れる（例 feature/1234-user-search）と、課題管理と結びつけやすくなります。

コンフリクトを減らす習慣

• ブランチは小さく、短命に保つ（大きくなるほど衝突しやすい）
• こまめに main の変更を取り込む
• 1ブランチ＝1目的に絞る

まとめ

迷ったら、まずはGitHub Flowから始めるのが無難です。「mainは常に動く」「作業はブランチで」「マージはレビュー後」——この3原則さえ守れば、多くのトラブルは防げます。基本のGitコマンドとあわせて押さえておきましょう。