Gitを使用して製品のさまざまなバージョンを管理しようとしています。これを行うにはいくつかの方法があります。私は、「マスター」ブランチを持ち、そのマスターブランチに沿ってさまざまなポイントにラベルを付けて、ソリューションの名前付き「バージョン」を構成するという概念に精通しています。たとえば、ある時点で、現在のビルドが私の製品の「RP_2012」ビルドを表すと判断する場合があります。後で、いくつかの機能が追加された後、「RP_2013」バージョンなどが存在する可能性があります。
特定の「バージョン」で開発が終了したとしても、バグ修正をロールアウトする必要があるかもしれません。たとえば、私がAzureで作業していて、各顧客がマルチテナンシー契約ではなく独自のバージョンのソリューションを持っているとします（そうすることで、支払いを希望する場合に新しいバージョンの製品を提供できるようになるためです。アップグレードすると、新しい機能を課すのではなく、アップグレードの準備ができるまで、快適な古いバージョンの製品を使用できます）。TeamCity、FluentMigratorなどを組み合わせて使用するスクリプトがあり、特定の顧客が持っているバージョンを取得して、既存のデータを保持しながら自由にアップグレードできます。それで、
上記のようにラベル付きバージョンのアプローチと単一の「マスター」ブランチを使用する場合、そのようなバグ修正を展開することは不可能かもしれません。代わりに、各バージョンに独自のブランチを与えると、各「バージョン」ブランチの祖先から派生した個別のブランチでバグ修正を実行し、後でその1つのブランチをいくつかの異なるバージョン固有のブランチにマージすることが可能でしょうか。枝？または、Rebaseを使用して、バージョン10、11、12に影響するバグ修正があり、それらの「バージョン」がマスターブランチに沿ったポイントとラベル付けされている場合、そこから分岐できるようにするための賢い方法はありますか？マスターで「バージョン10」とラベル付けされたポイント、および何らかの形でマスターをリベースして、上記のバグ修正ブランチで行われる修正に基づいて、これにより、バージョン10以降のすべてが、特定のブランチアドレスの修正から利益を得ることができますか？同時に、もちろん、新しい機能は、マスターのヘッドから分岐してマージすることによって実行されます。
私の質問と根本的な意図が十分に明確であることを願っています。基本的に、特定の製品のさまざまなバージョンを1つのマスターブランチに保持するのが最善かどうかを知りたいと思います。そして、もしそうなら、必要なときに/必要に応じて各バージョンにロールインできるバグ修正を実装するための最良の方法。これには、単一のブランチを複数の個別の子孫ブランチにマージすることが含まれる場合があります。または、すべてのバージョンが存在する単一のブランチをリベースする必要がある場合もあります。あるいは、皆さんはもっと賢い方法を知っているかもしれません。
提案を事前に感謝します。