Gitflow, GitHub flow, GitLab flow, Git Feature flow, Truncate Based Development のまとめ
目次
概要
これまで、以下の５つのブランチを戦略を紹介しました。
他にもブランチ戦略いくつかあるかと思いますが、本記事ではこれらのブランチ戦略をもとに、それぞれ著者が考えるメリット・デメリット etc. をついて書きます。
本記事ではそれぞれの手法を比較するために、開発ブランチと本番ブランチという言葉を使って比較します。
本番ブランチは本番（製品）に近い状態のブランチのことを指し、それ以外で本番に近いブランチを開発ブランチとします。
開発ブランチはブランチ戦略によって、プレリリースするためのブランチを意味することもあれば、ただ QA をするためのブランチを意味することがあります。ご了承願います。
最後に、本記事は著者が考える見解等が記述されています。必ずしも正解のものだと思わないでください。
Gitflow
開発ブランチが develop、 本番ブランチが main です。
開発時の流れ
- 開発ブランチから feature ブランチを作成
- feature ブランチを開発ブランチにマージ
- 開発ブランチがある程度進んだら、release ブランチを作成（またはマージ）
- release ブランチにて QA を実施、main にマージする前の修正を実施
- main に マージ、本番デプロイ
- 本番にてエラーが出たら、本番から hotfix ブランチを派生
- hotfix ブランチを main、develop にマージ
特徴
- それぞれのブランチに特定の役割を持つ
- Hot Fix は 本番ブランチから派生
メリット
- 役割ごとに分かれているため、ブランチが区別しやすい
- 開発、本番ブランチを分けることでそれぞれの環境で QA することができる
デメリット
- 慣れるのに時間がかかる
- やや複雑
運用に適した場面
- QA をリリース直前に実施したい時
GitHub flow
開発ブランチ、本番ブランチ共に main です。
開発時の流れ
- 本番ブランチから feature ブランチを作成
- feature ブランチを本番ブランチにマージ
特徴
- main 一つで開発
メリット
- ブランチが一つのため、シンプル
デメリット
- 一つの環境でしかQAできない
運用に適した場面
- チームメンバーが少ない時
- それぞれのブランチが 本番環境に近い QA ができる時
GitLab flow
開発ブランチが main、 本番ブランチが production です。
開発時の流れ
- 開発ブランチから feature ブランチを作成
- feature ブランチを開発ブランチにマージ
- 開発ブランチがある程度進んだら、 pre-production ブランチを作成（またはマージ）
- pre-production ブランチにて QA を実施、修正を要する場合は上から再度繰り返し
- pre-production から production にマージ、本番デプロイ
- 本番にてエラーが出たら、 開発ブランチから hotfix ブランチを作成
- hotfix ブランチを pre-production にマージ、後に pre-production から production にマージ
特徴
- 本番デプロイ前に複数のステージを介してデプロイする
メリット
- 開発〜本番ブランチの間で複数のブランチがあることでそれぞれの環境で QA をすることができ、本番へのリリースが安全
- 開発時に認識するべきブランチの範囲が Github flow と比べて小さいため、混乱しにくい（pre-production 等は意識しなくて良い）
デメリット
- Hot Fix 時の対応が遅い
運用に適した場面
- リリースにおいて開発、本番の間で複数の QA を実施したい時
Git Feature flow
開発ブランチが develop、本番ブランチが main です。
開発時の流れ
- 開発ブランチから feature ブランチを作成
- feature ブランチを開発ブランチにマージ
- QA を実施後、feature ブランチを本番ブランチにマージ、本番デプロイ
- 本番にてエラーが出たら、 本番ブランチから hotfix ブランチを作成
- 修正後、本番ブランチにマージ、本番デプロイ
特徴
- 開発ブランチと本番ブランチは独立
- 開発ブランチは本番に向くことはない
メリット
- QA 環境を一つにできる
デメリット
- feature ブランチがたくさんあると、どれを開発・本番にマージしたかがわからなくなる
- 開発ブランチが本番リリースしないものも含めて、マージされる
運用に適した場面
- 本番ブランチと開発ブランチの環境に乖離があった時
- QA 環境を一つにしたい時
Truncate Based Development
開発ブランチ、本番ブランチ共に main です。
開発時の流れ
- 本番ブランチから feature ブランチを作成
- feature ブランチを本番ブランチにマージ
特徴
- 毎日、本番ブランチに向けてマージ
メリット
- 大きな開発・改修ができない (結果、負債を抱える可能性あり)
- 本番ブランチの CI をより有効活用することができる
デメリット
- 大きな開発・改修ができない (結果、負債を抱える可能性あり)
- 開発途中のものがたくさんあると、新機能作成時にバグが発生する可能性歯ある + 最後にならないと完成系が見えない
運用に適した場面
- 機能を細かく分けられる時
最後に
いくつかブランチ戦略を紹介しました。
よくある話題としてどれを使うかという話があるかもしれませんが、個人的にはどれがいいかはなく、結局チームの開発体制・状況に応じてどれを適用するかを考えればいいです。 つまり、場合によって一部使うこともあれば、それらを組み合わせる必要があります。
結局これらのブランチ戦略は提唱者が取り組んだ経験から抽出した共通解でしかないので、必ずしも皆さんの開発体制に当てはまるものではないです。 無理に枠に当てはめるのではなく、状況に応じてうまく戦略を活用してください。
