同じソフトウェアの異なるエディションを維持するためにブランチを使用することは良い習慣ですか？
いくつかの異なるエディションがある製品があります。違いはわずかです。文字列があちこちで異なること、一方に追加のロジックがほとんどないこと、もう一方にロジックの違いがほとんどないことです。ソフトウェアの開発中は、ほとんどの変更を各エディションに追加する必要があります。ただし、必要なものとそうでないものがあります。 release-editionAおよびrelease-editionB（..etc）ブランチがある場合、それはブランチの有効な使用ですか？落とし穴はありますか？良い習慣？
更新：皆さんの洞察に感謝します。たくさんの良い答えがここにあります。一般的なコンセンサスは、この目的でブランチを使用することは悪い考えであるようです。疑問に思う方のために、問題に対する私の最終的な解決策は、文字列を構成として外部化し、異なるロジックをプラグインまたはスクリプトとして外部化することです。
これは変更の規模に依存しますが、私はあなたが説明した違いのためにそれが良い習慣であるとは思いません。
一般的に、Gitブランチは、将来マージされるか、参照用に読み取り専用で保管されるものにする必要があります。無期限に共存するGitブランチは、すべての人の作業を意味します。変更は、伝達およびマージする必要があり、競合は解決する必要があります。他に何もない場合、すべての開発者は変更を1つではなく5つのリポジトリにプッシュすることを忘れないでください。
小さな変更がある場合、問題と比較すると、全体のマージとブランチ維持の努力はやり過ぎに見えます。プリプロセッサまたはビルドシステムを使用して、バージョンを区別します。単純な#ifdefトリックはありますか？それからgitで問題を解決しないでください、それはやり過ぎです。
それは実際にはブランチの目的ではありません。ブランチは、同じコードの長期の並列バージョンではなく、開発ラインへの短期から中期のサイドパスであると想定されています。
エディション間で異なるパーツのサブディレクトリを使用して、すべての異なるバージョンを同じブランチに入れ、ビルドプロセスをセットアップして（自動ビルドがありますよね？）、どちらのエディションもオンデマンドで出力できるようにします（または一度にすべて）。
結局のところ、「真実の単一の情報源」を維持したいのです。ブランチを使用すると、すべてではなく一部のコードを複製することになり、特定のマージは実際に設定を壊します。
人々が指摘したように、1つの解決策は、異なるエディションをサポートするようにビルドシステムを構成することです。
また、機能の切り替えとして構成ファイルを使用することも検討します。構築する必要がある数が少ないほど、優れています。
コードをクラスタリングしなければ、1つのブランチ内でそれを実行できないのであれば、それは良い考えだと思います。
特に違いが小さいと言う場合は、1つのブランチに保持し、ローカライズされた構成ファイルを使用できるようにしたいと思います。
別の方法としては、ビルドが異なる可能性があります。たとえば、ビルドファイルは異なる顧客用に異なるファイルをパックしますが、ビルドツールが異なるブランチをチェックアウトすることも確認できます。 gitを使用しているので、実際の問題はありません。分岐戦略の1つは、さまざまなタスクのさまざまな分岐で開発し、マスター分岐にチェックインして、マスターからeditionXおよびYにマージすることです。
これは、異なるビルド構成の仕事のように聞こえます。 thitonの回答 はこの方向に進みますが、私は#ifdef：
異なるビルドターゲットを使用して、ソフトウェアの異なるエディションをビルドします。ターゲットは異なる場合があります
- それらが含む構成、
- それらが含むオブジェクトまたはソースファイル、または
- ソースコードの前処理。
この前処理には、明らかに従来のCプリプロセッサが含まれている可能性がありますが、カスタムプリプロセッサ、テンプレートエンジンを使用してカスタムビューを作成することなどが必要になる場合もあります。
これにより、すべての変更を複数のブランチに積極的にプッシュする必要がなくなり、DRYに違反します（もちろん、自動化することもできますが、利点はわかりません）。
私は重要な変更にのみブランチを使用します。そうしないと、多数のブランチにすべての小さな変更が追加されてしまいます。これは、特に面白くなく、特により多くの人と作業している場合、エラーが発生しやすくなります。
それらをすべて異なる製品としてリリースする場合は、複数のブランチを持つことをお勧めします。そうでない場合でも、トランクやマスターブランチなどを使用することをお勧めします。
また、これは開発プロセス、特に展開に依存すると思います。 1つのブランチのみを本番環境にロールアウトできるプロセスがあり、ブランチが「増分ビルド」として扱われている場合、リリースAが最初にロールアウトされない限り、リリースBは本番環境にロールアウトできません。 AはすでにBにあり、複数のブランチを持つことが先決です。これは、チームが世界中に散らばっていて、通常、優先順位に従って変更が行われている場合に機能します。