Gitブランチ戦略比較
Git Flow
developブランチ, masterブランチが前提(ブランチベース開発)
Pros
developが存在することでリリースタイミングの調整が出来る
masterから切ったfeatureブランチをdevelopにmerge、その後QAにかけてQAを通ったらmasterにマージする等
Cons
developとmasterの差異が大きくなる
masterにマージする度に再度毎回テストが走る
もし各フィーチャーブランチごとにQAを通ったとしてもそれがmasterにマージされた際には再度テストしないといけない(テストした時点よりmasterのコミットが進んでいる場合があるので)
リリースサイクルが遅くなる(週一など)
とりあえずdevelopにコミットすればいい、QAすればいいという意識が生まれるのでコードの品質が下がる、またレビューするという意識が希薄になる
また一度にテストしなければいけない箇所が増えるためQAの負担が増える
コードレビューするにも大量のコードをレビューしないといけないのでバグの兆候を見逃す確立も上がりレビューの品質も下がる
一回当たりの変更バッチが大きくなるとレビューの間に別の機能を開発、またその開発が前のレビューから影響を受ける場合変更が発生する等のコンテキストスイッチコストが大きくなる
基本的にビッグバンリリースになりがち
人数が増えるほどブランチ間のコンフリクト、QA待ち等で開発がスケールしなくなる
フューチャブランチの発展は継続的インテグレーションの衰退である
インテグレーションフィーチャーブランチはGitFlowを使って6ヶ月程やってみましたが,まったくお勧めできません。
常に動作するmasterが存在するという前提でフィーチャーブランチを切る開発
Pros
常にmasterが動作する前提で一本化するためリリースサイクルが早くなる
CI/CDによるテスト、レビューが前提となるためコードを綺麗にする、テストを書くという習慣が生まれるためコードの品質を上げる意識が生まれる
コミットを意識しレビュー、テストを書くことによりジュニアレベルの開発者の成長が早くなる
一回ごとの変更の差分を小さくすることを意識するためQAの負担も下がりQAプロセスも早く回る
Cons
リリースの調整はタグを打ったら等の決めは必要
フィーチャーブランチで開発していくことはGit Flowと同じなので同様にマージのためのコストが増えるが一回当たりの変更量を小さくしようとする意識が働くのでGit Flowほど問題が顕在化しない印象. 各フィーチャーブランチの変更量を小さくすることや依存する変更を先に出すなど気をつける必要はある
ビルドフィーチャーブランチは客先で,GitHub Flowを使って1年ほど行いました。お勧めできますが,ただし慎重さが必要です。
特定のフィーチャーのみをコードフリーズしてテストしたい場合は別途考える必要はある
featureトグル, masterは常にステージングにデプロイしていつでもQA可能で問題ないようにする等
GitHub Flowにpre-production, productionなどリリース調整用のブランチを生やす戦略
Pros
リリースサイクルの調整が出来る
Cons
ブランチが増えることによる
Slack上で明示的にmerge?もしくはGitHubのPR上でコメントでmerge出来るようにする?
/merge into pre-productionなど
もしくはlabelを付与するとmergeされる(クリックミスで間違えてproductionにmergeしちゃいそうであれだが)
pre-productionはCI上でapproveせずに
メインラインを一つ(master)を用意し全てのコミットがそこで行われる開発 . GoogleやFacebookのモノレポによる開発はこれ
メインラインから切ったリリースブランチでのhotfixは適宜masterにマージされる
Pros
継続的インテグレーションを意識するため一時的に無効化したい機能はフィーチャートグルといったテクニックを使うことを意識する
QAレベルで機能の有効化、無効化が出来るため開発者のコミットとQAによる受け入れテストが並行して行える
Googleレベルで開発者が多い場合はフィーチャーブランチはコストが大きいので有効
フィーチャーブランチによるオーバーヘッドが存在しないため正しいテクニックを使えば安全に開発しつつ素早く開発することが可能
Cons
シニアレベルでないとメインライン上で安全にコミットする(一回当たりの変更バッチを小さく保つ、そのためモジュール化する、一度の変更バッチの独立性を保つ、ローカル上でテスト可能なコードを書く、フィーチャートグルを使う、カナリヤリリースでユーザへの影響を小さくする、ロールバック等)継続的インテグレーションをするためのテクニックを知らないため危険
SREチームも十分に機能していて継続的インテグレーションをサポートする体制が整っていないと危険
向いている開発スタイル
Git Flow
リリースサイクルがゆっくりで問題ない場合、調整したい場合
保守運用フェーズなど
一度デプロイしたら後戻り出来ない開発の場合(コードフリーズが欲しい場合)
iOSやAndroid、パッケージ開発(早くて数週間に一回等のリリースサイクル)
GitHub Flow
リリースサイクルを早くして改善を早くしていきたい場合
多少おかしくてもリリースして改善していくというサーバサイド開発、フロントエンド開発など
プロジェクト立ち上げ時
初期リリースまでベロシティを稼ぎたい場合
開発者のスキルレベルが一定でない場合
OSS等
トランクベース開発
継続的インテグレーションで開発していきたい場合
フィーチャートグルやカナリヤリリース、CIによる自動テストでの高いカバレッジなど継続的インテグレーションをサポートする体制が整っている、もしくはしていくことが出来るメンバーがいる
フィーチャーブランチによるオーバーヘッドが無視出来ないほど大きくなった場合
併用案
サーバサイド開発においてGit Flowはオーバーヘッドが大きいので開発初期に採用すると出力が出ない
GitHub Flowはリリース管理を考える必要がある
↓
ロンチ前の初期リリースまではGitHub Flowで出力を稼ぐ
保守運用フェーズなどリリース管理をしていきたいというタイミングになったらGit Flowに切り替える
といってもタグリリースすればリリース管理出来るのでGitHub Flowでもほぼ問題ないとは思う