バージョン管理で同じコードベースから2つの異なるソフトウェアバージョンを維持する

同じソフトウェア/プログラム/アプリ/スクリプトの2つの異なるバージョンを作成し、バージョン管理下に保存しているとしましょう。最初のバージョンは無料の「ベーシック」バージョンで、2番目は有料バージョンの「プレミアム」バージョンで、無料バージョンのコードベースを取得し、いくつかの付加価値機能で拡張します。新しいパッチ、修正、または機能は、両方のバージョンへの道を見つける必要があります。

現在、有料版のサイドとブランチに沿って、メインコードベース（無料版）のブランチを使用することmasterを検討していdevelopます。無料版に変更が加えられ、ブランチにマージされると（もちろん徹底的なテストの後）、さらにテストするためにコマンドを介してブランチにコピーされ、にマージされます。master-premiumdevelop-premiummasterdevelopdevelop-premiumcherry-pickmaster-premium

これは、この状況を処理するのに最適なワークフローですか？認識すべき潜在的な問題、警告、または落とし穴はありますか？私がすでに思いついたものよりも良い分岐戦略がありますか？

あなたのフィードバックは大歓迎です！

PSこれはGitに保存されているPHPスクリプト用ですが、回答はすべての言語またはVCSに適用する必要があります。

共通のベースを持つ2つのコードバージョンを使用する代わりに、これらのプレミアム機能をプラグ可能にし、異なるコードベースではなく構成によって駆動するようにアプリケーションを設計する必要があります。

基本バージョンでこれらのプレミアム機能（構成により無効）を出荷することを恐れている場合でも、最終ビルド/パッケージング手順でそのコードを削除し、2つのビルドプロファイルのみを保持できます。

このデザインを使用すると、5種類のフレーバーを出荷し、非常に柔軟になり、サードパーティが貢献することもできます。

この目的でブランチを使用しないことを強くお勧めします。一般に、後で再びマージされる（またはマージされる可能性のある）ブランチ（またはブランチの1つの開発を最終的に停止するリリースブランチ）のブランチを検討する必要があります。あなたの場合、「基本」バージョンと「プレミアム」バージョンをマージすることはありません。これらは両方とも無期限に維持されるため、ブランチは適切ではありません。

代わりに、ソースコードの1つの共通バージョンを維持し、条件付きコンパイル（たとえば#ifdef、C / C ++では、PHPに相当するものがわからない）を使用して、「基本」と「プレミアム」で異なるコードのセクションを含めたり除外したりします。

PHPにはそのような条件付きコンパイル機能が組み込まれていないように見えるため、Cプリプロセッサ（cpp、おそらく既に持っている）を使用して共通のソースコードを前処理し、そこから「基本」および「プレミアム」を生成できますプリプロセッサディレクティブのないバージョン。もちろん、これを行うことを選択した場合はmake、プリプロセッサを実行するプロセスを自動化するために、または同様のものを使用する必要があります。

基本プロジェクトと、基本プロジェクトに依存するプレミアムプロジェクトの2つの別個のプロジェクトを使用しています。ブラケットは使用しないでください。通常は、機能に使用されます。

現在のほとんどの答えはブランチではなく条件付きコンパイルを支持していますが、ブランチを使用することには明確な利点があるシナリオが1つあります。バージョン履歴がすべてのプレミアム機能を除外している場合、ブランチアプローチを使用することはできますが、単一のブランチと条件付きコンパイルを使用することはできません。

さくらんぼ狩りに反対し、代わりに基本バージョンからプレミアムバージョンにすべての変更をマージします。基本バージョンには含まれるが、プレミアムバージョンにはない機能またはバグ修正はありません。物事をできる限り簡単にするために、premiumブランチが共通ファイルをできるだけ変更しないようにする必要があります。そのため、プレミアムブランチには主に追加のファイルが含まれている必要があり、おそらくビルド手順に若干の変更が必要です。これにより、基本バージョンからの変更は、競合を引き起こすことなく自動的にマージされます。

Gregの回答は、「後で再びマージされる（またはマージされる可能性のある）ブランチを検討する」ことを示唆しています。先ほど説明したアプローチでは、これが事実です。ただし、すべてのコミットの最終ブランチはそうではありmaster-premiumませんmaster（実際にはそうですmaster-basic）。

もちろん、サブモジュールもオプションになります。ビルドプロセスに依存しますが、基本バージョンをモジュールとして使用するプロジェクトにプレミアムバージョンを作成できる場合は、問題ありません。ただし、ある時点で機能をプレミアムブランチからベーシックブランチにチェリーピッキングすることに決めた場合は、苦労するかもしれません。サブモジュールでは、このような変更は2つの別個のコミットとして表されますが、ブランチでは、これは基本バージョンへの単一コミットであり、プレミアムバージョンへの次回のマージでは、これらの変更がすでに含まれており、再びマージされます。

「ハードウェア」では、これは頻繁に行われます。これらは混乱を制御するために販売されているシステムです。

「ミッドレンジ」洗濯機が出荷されると、数か月後に出荷される「ローエンド」洗濯機で同じコードが変更された場合でも、非常に重要なバグ修正以外のコードは変更されません。

顧客はすでに持ってきた洗濯機へのアップグレードを期待していません。新しいモデルも数ヶ月ごとに出荷されません。

私たちのほとんどはその世界に住んでいないので、洗濯機用のソフトウェアを書いているのでない限り、グレッグが言うことをしてください。