ブランチ戦略

ブランチ戦略とは

ブランチ戦略は、[[Git]] のブランチをチームでどう作り、どうマージするかの取り決めです。ブランチの切り方がバラバラだと、マージの衝突やリリース事故が起きやすくなります。戦略を決めることで、開発からリリースまでの流れが予測可能になります。

代表的な戦略

GitHub Flow の基本サイクル

最も広く使われる GitHub Flow は、次のサイクルを繰り返します。

1. main から作業ブランチを切る(feature/login など)
2. コミットを積んでプッシュする
3. プルリクエストを出してコードレビューを受ける
4. CI のテストが通り、承認されたら main にマージ
5. main からデプロイする

main は常にデプロイ可能な状態に保つのがルールです。壊れた状態のコードを main に入れないため、[[コードレビュー]] と自動テストがゲートの役割を果たします。

戦略選びの考え方

• リリース頻度が高いほどシンプルな戦略が向きます。Web サービスなら GitHub Flow が第一候補です
• 「v1.2 系を保守しながら v2.0 を開発する」ような複数バージョンの並行保守が必要なら Git Flow 系が候補になります
• ブランチの寿命は短いほど安全です。長生きしたブランチほどマージが大変になるのは、どの戦略でも共通の真理です
• 未完成の機能を隠しながら main に統合したい場合は [[フィーチャーフラグ]] を併用します

初学者向けポイント

• まずは GitHub Flow を体で覚えましょう。「main から切る → PR を出す → レビュー後にマージ」だけで実務の大半をカバーできます
• ブランチ名は feature/〜 fix/〜 のように種類が分かる命名規則にするのが定番です
• マージの方法(マージコミット・スカッシュ・リベース)はチームの取り決めに従いましょう。履歴の見え方が変わります
• どの戦略を使うかより「チーム全員が同じルールを守っている」ことの方が重要です

関連技術とのつながり

• [[Git]] — ブランチ戦略の土台となるバージョン管理システム
• [[コードレビュー]] — マージ前のゲートとしてブランチ運用に組み込まれる
• [[CI/CD]] — ブランチへのプッシュを起点にテスト・デプロイを自動化する
• [[デプロイ戦略]] — main にマージした後、どう本番に出すかを扱う
• [[フィーチャーフラグ]] — 未完成機能を隠しつつ小さくマージするための道具

Q: GitHub Flow の基本ルールとして正しいのはどれ?
- [x] main を常にデプロイ可能な状態に保つ
- [ ] main には直接コミットし、ブランチは作らない
- [ ] リリースのたびに develop ブランチを作り直す
解説: GitHub Flow では main から作業ブランチを切り、レビューとテストを通ったものだけをマージして main を常に健全に保ちます。

Q: 複数バージョンの並行保守が必要な製品に向くとされる戦略はどれ?
- [ ] GitHub Flow
- [x] Git Flow
- [ ] ブランチを一切使わない運用
解説: develop・release・hotfix など多層構成の Git Flow は、バージョンを区切ってリリース・保守する製品に向きます。

Q: ブランチの寿命について本文が述べているのはどれ?
- [ ] 長く育てたブランチほどマージが簡単になる
- [x] 長生きしたブランチほどマージが大変になる
- [ ] ブランチの寿命はマージの難易度と無関係である
解説: ブランチが長生きするほど main との差分が広がり、マージの衝突や手戻りが増えます。短命に保つのが安全です。