バージョン管理での同じコードベースからの2つの個別のソフトウェアバージョンの維持
同じソフトウェア/プログラム/アプリ/スクリプトの2つの異なるバージョンを作成して、バージョン管理下に保存しているとしましょう。最初のバージョンは無料の「ベーシック」バージョンで、2番目のバージョンは無料の「プレミアム」バージョンで、無料バージョンのコードベースを利用して、いくつかの付加価値のある機能を追加します。新しいパッチ、修正、または機能は、両方のバージョンに組み込まれる必要があります。
現在、メインコードベース（無料バージョン）のmasterブランチとdevelopブランチを、有料バージョンのmaster-premiumブランチとdevelop-premiumブランチとともに使用することを検討しています。無料バージョンに変更が加えられてmasterブランチにマージされると（もちろんdevelopで徹底的にテストした後）、さらにテストするためにdevelop-premiumコマンドを介してcherry-pickブランチにコピーされます次にmaster-premiumにマージされます。
これは、この状況を処理するための最良のワークフローですか？知っておくべき潜在的な問題、警告、または落とし穴はありますか？私がすでに考えているよりも良い分岐戦略はありますか？
あなたのフィードバックは大歓迎です！
追伸これはPHPスクリプトがGitに保存されているためのものですが、答えはすべての言語またはVCSに適用されます。
共通のベースを持つ2つのコードバージョンを使用する代わりに、これらのプレミアム機能をプラグイン可能にし、異なるコードベースではなく構成によって駆動されるようにアプリケーションを設計する必要があります。
基本バージョンでこれらのプレミアム機能（構成により無効化）を出荷することを恐れている場合でも、最終的なビルド/パッケージ化ステップでそのコードを削除して、2つのビルドプロファイルを作成できます。
このデザインを使用すると、5つの異なるフレーバーを出荷して非常に柔軟にでき、サードパーティによる貢献も可能になります。
notこの目的でブランチを使用することを強くお勧めします。一般に、後で再びマージされる（またはマージされる可能性がある）ブランチ（または、いずれかのブランチの開発を最終的に停止するリリースブランチ）のブランチを検討する必要があります。あなたの場合、「ベーシック」バージョンと「プレミアム」バージョンをマージすることは決してなく、それらは両方無期限に維持されるため、ブランチは適切ではありません。
代わりに、ソースコードの1つの共通バージョンを維持し、条件付きコンパイルを使用します（例：#ifdef C/C++では、PHPの同等の機能がわからないため）「基本」と「プレミアム」で異なるコードのセクションを含めたり除外したりします。
PHPにはこのような条件付きコンパイル機能が組み込まれていない可能性があるため、Cプリプロセッサ（cpp、おそらくすでに持っている）を使用して共通ソースを前処理できます）コードとそれから、プリプロセッサディレクティブなしで「基本」バージョンと「プレミアム」バージョンを生成します。もちろん、これを選択する場合は、makeまたは同様のものを使用して、プリプロセッサの実行プロセスを自動化する必要があります。
基本プロジェクトと基本プロジェクトに依存するプレミアムプロジェクトの2つの別々のプロジェクトを使用しています。ブラケットは使用しないでください。通常、フィーチャーに使用されます。
現在の答えのほとんどはブランチではなく条件付きコンパイルを支持していますが、ブランチを使用することの明らかな利点があるシナリオが1つあります。（現在または後で）基本バージョンのソースコードをすべて利用可能にすることを決定した場合バージョン履歴ですが、すべてのプレミアム機能を除外しているので、ブランチアプローチで行うことができますが、単一ブランチと条件付きコンパイルではできません。
私はチェリーピッキングに反対し、代わりにベーシックバージョンからプレミアムバージョンにall変更をマージします。ベーシックには機能やバグ修正は含まれていませんが、プレミアムバージョンにはありません。物事をできるだけ簡単にするために、プレミアムブランチが共通ファイルをできるだけ変更しないようにする必要があります。したがって、プレミアムブランチには、ほとんどの場合、追加のファイルと、ビルド命令のいくつかのわずかな変更が含まれているはずです。このようにして、基本バージョンからの変更は、競合を引き起こすことなく自動的にマージされます。
Gregの答え は、「後で再びマージされる（またはマージされる可能性がある）ブランチについて検討する」ことを提案しました。すべてのコミットの最後のブランチがmaster-premiumではないmaster（実際にはmaster-basic）。
もちろん、サブモジュールもオプションになります。ビルドプロセスによって異なりますが、プレミアムバージョンを、基本バージョンをモジュールとして使用するプロジェクトにできる場合は、それで問題ありません。ただし、ある時点で、プレミアムブランチからベーシックブランチに機能をチェリーピックする場合は、さらに困難になる可能性があります。サブモジュールでは、このような変更は2つの異なるコミットとして表されますが、ブランチでは、これは基本バージョンへの単一のコミットであり、プレミアムバージョンへの次のマージでは、これらの変更がすでに含まれていて、再びマージされます。
「ハードウェア」ではこれが頻繁に行われます。これらは混乱を制御するために販売されているシステムです。
「ミッドレンジ」の洗濯機が出荷されると、数か月後に出荷される「ローエンド」の洗濯機で同じコードが変更されても、非常に重要なバグ修正以外はコードは変更されません。
お客様は、すでに持っている洗濯機へのアップグレードを期待していません。新しいモデルも数か月ごとに出荷されるわけではありません。
私たちのほとんどはその世界に住んでいません。洗濯機用のソフトウェアを作成しているのでない限り、グレッグの言うとおりにしてください。