ブランチ戦略に唯一の正解はありません。チームの規模、リリース頻度、デプロイの自動化度合いに合わせて選ぶのが原則です。

GitHub Flow（おすすめの初期解）

mainから機能ブランチを切り、PR→レビュー→マージ→即デプロイ。シンプルでCIとの相性がよく、多くのWeb開発に適します。

Git Flow

develop/release/hotfixを厳密に分ける方式。リリースをまとめて出す・複数バージョンを保守する製品には有効ですが、Webサービスにはやや重厚です。

Trunk-based

短命ブランチ（1日以内）でmainに頻繁にマージ。フィーチャーフラグと自動テストが前提で、高速にデプロイする成熟チーム向けです。

共通で守りたいこと

  • PRは小さく保つ（レビュー負荷とコンフリクトを減らす）
  • コミットメッセージは「なぜ」を書く
  • mainは常にデプロイ可能な状態を維持する