master ＋ 機能ブランチ運用の落とし穴と限界はじめに master と feature だけで回すブランチ運用は、シンプルで分かりやすい反面、 規模や変更の幅が少しずつ広がると「限界」が見え始めます。 本記事では、よくある落とし穴と、今は大丈夫に見えてしまう理由、 そしてどのタイミングで次の一手を考えるべきかを整理します。 複数修正の一括リリースとブランチ戦略の関係 1. 前提の開発フロー ブランチ構成 master：本番相当の安定ブランチ feature/○○：機能開発用ブランチ（タスク単位で作成） 運用フロー 古い master から feature/○○ を作成 対象の feature ブランチを QA 環境にデプロイしてテスト QA 完了後、feature → master にマージ develop や staging ブランチはなく、 master ＋ feature だけのシンプル構成になっている。 2. 一般的に起きや
