ブランチを使用して同じソフトウェアの異なるエディションを維持することは良い習慣ですか？

いくつかの異なるエディションを持つ製品があります。違いはわずかです。異なる文字列があり、一方のロジックはほとんど追加されておらず、もう一方のロジックはほとんど違いがありません。ソフトウェアの開発中は、ほとんどの変更を各エディションに追加する必要があります。ただし、そうでないものと異なる必要があるものがいくつかあります。release-editionAおよびrelease-editionB（..etc）ブランチがある場合、ブランチの有効な使用ですか？落とし穴はありますか？良い習慣？

更新：皆さんの洞察に感謝します。多くの良い答えがここにあります。一般的なコンセンサスは、この目的のためにブランチを使用することは悪い考えだと思われます。不思議に思う人にとって、この問題に対する私の最終的な解決策は、構成として文字列を外部化し、プラグインまたはスクリプトとして異なるロジックを外部化することです。

これは変更の大きさに依存しますが、あなたが説明した違いについては良い習慣だとは思いません。

一般的に、Gitブランチは、将来的にマージされるか、参照用に読み取り専用で保存されるものにする必要があります。共存するGitブランチは、すべての人の作業を意味します。変更を伝播してマージする必要があり、競合を解決する必要があります。それ以外の場合は、すべての開発者が変更を1つではなく5つのリポジトリにプッシュすることを忘れないでください。

小さな変更がある場合は、問題と比較すると、マージとブランチ管理の作業全体が過剰に思えます。プリプロセッサまたはビルドシステムを使用して、バージョンを区別します。単純な#ifdefトリックはありますか？gitの問題を解決しないでください、やり過ぎです。

それは実際にはブランチの目的ではありません。ブランチは、開発ラインへの短期から中期のサイドパスであり、同じコードの長期的な並列バージョンではありません。

エディション間で異なる部分のサブディレクトリを使用して、すべての異なるバージョンを同じブランチに配置し、ビルドプロセスをセットアップして（自動ビルドを使用しているのですか？）、どちらかのエディションをオンデマンドで出力できるようにします（または一度にすべて）。

結局のところ、「単一の真実の源」を維持したいのです。ブランチを使用すると、一部のコードを複製することになりますが、すべてではありません。また、特定のマージによって実際にセットアップが中断されます。

解決策の1つは、人々が指摘しているように、異なるエディションをサポートするようにビルドシステムを構成することです。

また、機能の切り替えとして実装し、構成ファイルを使用することも検討します。構築する必要があるものが少ないほど良い。

このサイトをご覧ください。

コードを大量にクラスタ化しないと、1つのブランチ内でそれを行うことができないのであれば、それは良い考えだと思います。
特に違いが小さいと言う場合は、1つのブランチに保持し、ローカライズされた構成ファイルを使用できるようにしたいと思います。
別の方法としては、ビルドが異なる場合があります。たとえば、ビルドファイルは顧客ごとに異なるファイルをパックしますが、ビルドツールがさまざまなブランチをチェックアウトすることも確認できます。あなたがgitを使用するとき、私は本当の落とし穴はないと言います。分岐戦略の1つは、さまざまなタスクのさまざまなブランチで開発し、マスターブランチにチェックインし、マスターからeditionXおよびYにマージすることです。

これは、異なるビルド構成の仕事のように聞こえます。チトンの答えはこの方向に行きますが、私はそれよりもはるかに遠くにそれを取るでしょう#ifdef：

異なるビルドターゲットを使用して、ソフトウェアの異なるエディションをビルドします。ターゲットは

• 含まれる構成、
• 含まれるオブジェクトまたはソースファイル、または
• ソースコードの前処理。

この前処理には、明らかに古典的なCプリプロセッサが含まれますが、カスタムプリプロセッサ、カスタムビューを構築するためのテンプレートエンジンの使用を伴うこともあります。

この方法では、すべての単一の変更を複数のブランチに積極的にプッシュする必要がなくなり、DRYに違反します（もちろん、それも自動化できますが、利点はわかりません）。

重要な変更にのみブランチを使用します。そうしないと、多数のブランチに小さな変更をすべて追加することになります。これはまったく楽しくなく、特により多くの人と作業している場合は非常にエラーが発生しやすくなります。

それらをすべて異なる製品としてリリースする場合は、複数のブランチを持つことをお勧めします。そうでない場合でも、トランクまたはマスターブランチのようなものを使用することをお勧めします。

また、これは開発プロセス、特に展開に依存すると思います。1つのブランチのみを実稼働環境にロールアウトできるプロセスがあり、ブランチが「増分ビルド」として扱われている場合、リリースAが最初にロールアウトされない限り、リリースBは実稼働環境にロールアウトできないことを意味します。 AはすでにBにいるので、複数のブランチを作成する方法があります。これは、世界中に散らばったチームがあり、通常は優先順位に従って変更を行う場合に機能します。

3つの異なるブランチ（プロダクション、開発、機能用）を備えたソリューションは非常にうまく機能します。本番コードでバグを発見した場合、パッチを適用してリリースすることができます。実稼働ブランチに機能を追加したり、実稼働ブランチに大きな変更を加えたりしないでください。あなたとあなたのチームは、本番ブランチに大きな機能変更を加えないように自制する必要があります。本番ブランチは、本番コードベースの大きな変更を保証しないマイナーなバグ修正のためだけのものです。