プロダクトライン開発におけるgitブランチモデルの選定について

Question

gitのブランチモデルについて質問です。

私は組み込みソフトの分野にいるのですが、そこでは
各製品共通のコア部と、
それをもとに製品バリエーションごとの変動部を組み合わせて作る、
プロダクトライン開発が使われており、
そのバージョン管理にgitを取り入れたい場合、どのようなブランチモデルにすればよいかあまりイメージが湧かないため、意見を伺いたいです。

世間一般のgitブランチモデル(git-flow, GitHub Flow,...)についてはいろいろ参考にしたのですが、
どれも、「リポジトリ内で正しいのは、最新のmasterただ一つ」の方針のように見えます。
（ある時点時点でリリースはすると思いますが、「その時点の最新」のものをマークつけるだけで、ある程度時間が立ってからリリース時点のものに立ち返ることがないように見えました）

一方でプロダクトライン的な開発では、バリエーションを複数持つので、「リポジトリ内の正解」が複数できるように思います。

コア部
|- A国向け商品
|- B国向け商品
|- 企業A向け特注対応
のようなイメージです。

コア部をmasterにして、XX向け商品、をそれぞれbranch切ることも考えたのですが、どうもしっくりきません。

プロダクトライン開発にgitを使うには、どのようなブランチ戦略にするのが適切でしょうか？

組み込み以外でも、ある時点のソフトをベースにした、複数バリエーションのソフトを作って管理することはあるかと思いますが、どのように管理しているのかを知りたいです。

Answer 1

コア部

|- A国向け商品
|- B国向け商品
|- 企業A向け特注対応

Gitの戦略的には1つの素晴らしいプロダクトを作り上げていくものであり、
受注生産に近い事をやるならばその度にプロジェクトを分けるべきでしょう。

もしくはTwitterの言語対応のように全てが1プロジェクトに詰まっているような対応をして、
オブジェクトのプロパティやDB等でA国、B国、C企業向けというプロパティを持たせてやるとか

---

以下は今回の質問文全体を読んだ感想ですが、
ブランチ・プロジェクトで分けた時、同じコードをコピペしまくりで考えているのではありませんか？
すぐに横並び項目の対応漏れ等のやることが*nで増えていき、人員がパンクしてしまう事でしょう。

なのでコアな部分は抽象化して別プロジェクトに飛ばして、
ライブラリなりフレームワークとして利用する形にするべきでしょう。
共通部分はWordPressのコアなブログロジック、○○向け対応はWordPressのテーマとして別プロジェクトで作っておく。
こういう風な使い分けをすれば、後は設計を頑張ればスッキリした管理が出来るかと思います。

Answer 2

こんにちは。

バリエーション毎にブランチを分けるメリットは特になりように感じます。
１つのブランチには全てのバリエーションが含まれるのが一般的ではないでしょうか。
例えば、マルチプラットフォーム対応のOSSを良く使うのですが、私の知る限りでは全てのプラットフォーム用のソースが１つのブランチに含まれています。

ブランチは最終的にはmasterへマージするのが基本的な運用と思います。
git flowのdevelopブランチのようにmasterへマージする前にreleaseブランチを経由したり、マージ後もブランチが生き続けたりするような運用もありますし、中には開発を諦めたり中断したりしてマージしないこともありますが。