はじめに
開発が大きくなるほど、「どのブランチで何を進めるのか」「どこでまとめるのか」が曖昧になり、気づけば作業が散らばってしまうことがあります。
特に複数人で動くプロジェクトの場合、このあたりの運用ルールが曖昧だと、レビューが詰まったり、QAが想定以上に時間を取られたりと、後半の負担が一気に増えてしまいます。
この記事では、僕が普段プロジェクトを進める際に意識している プロジェクトブランチ と QAブランチ の役割や使いどころについて整理しておきます。
運用フローはチームによって違って当然ですが、ひとつの考え方として参考になれば嬉しいです。
プロジェクトの進め方
まず、プロジェクトが大きくなった時に便利なのが プロジェクトブランチ です。役割としては「この施策に関係する変更をひとまず全部ここに集める場所」というイメージです。
例えば、UI改善・API追加・文言調整など、複数のメンバーが各自の PR を積んでいくとき、main に直接積んでいくのは現実的じゃありません。
そこで feature/◯◯-project のようなブランチを作っておくと、実装途中のコードでも安全にまとめられるし、レビューも粒度を揃えやすくなります。
参考:
Git Branches（Git公式）
https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
プロジェクトブランチ配下の動きはこんな感じです。
main
└── feature/share-stocks-project
├── feature/share-ui
├── feature/share-api
└── fix/share-list-bug
この構造にしておくと、main を直接汚さずに大規模な開発を前に進めることができます。
さらに、プロジェクトブランチで一旦全体の整合性が取れれば、次のステップである QA をスムーズに通せるようになります。
QAブランチ
QAフェーズに入ったら、QAブランチ を用意してそこにプロジェクトブランチの成果物を集約します。
役割としては「main に乗せる直前の最終チェック場所」です。
ここで重要なのは、QAブランチには「とりあえず動く状態のものだけ」を載せることです。未完了の作業を置き始めると、動作確認が進まなくなり、結果的に全体の進行に影響します。
QAブランチは staging 環境のデプロイ先にも設定されやすく、デザイナー・PM・QA などプロジェクトメンバー全員が同じ環境で確認できるのがメリットです。
GitHub Flow の中では main 手前の確認ポイントに近いものとして扱われます。
参考:
GitHub Flow（GitHub公式）
https://docs.github.com/en/get-started/quickstart/github-flow
大まかな流れは次の通りです。
- main からプロジェクトブランチを作成
- プロジェクトブランチ配下で各タスクをPRとして積む
- 実装が揃ったら QAブランチへ統合
- QAで仕様漏れ・表示崩れ・エッジケースを確認
- 必要であれば修正→再度QA
- 問題なしになったら main へマージ
このループがきれいに回ると、プロジェクト全体の開発速度が驚くほど安定します。
おわりに
プロジェクトブランチと QAブランチは、どちらも「複数人で安全に前進するための仕組み」です。
ブランチ運用はチームによって最適解が変わりますが、共通して言えるのは “コードの流れが透明になるほどプロジェクトは安定する” ということです。
大規模な開発ほど混乱が起きやすいですが、ブランチの役割を分けておくだけで、レビュー担当・実装担当・QA担当が迷いにくくなり、結局プロジェクト全体の負担が軽くなります。
もし自分のチームで「最近ブランチまわりがぐちゃっとしてきたな…」という感覚があれば、一度プロジェクトブランチとQAブランチの役割を見直してみると改善のきっかけになるはずです。