1

Gitを使用して製品のさまざまなバージョンを管理しようとしています。これを行うにはいくつかの方法があります。私は、「マスター」ブランチを持ち、そのマスターブランチに沿ってさまざまなポイントにラベルを付けて、ソリューションの名前付き「バージョン」を構成するという概念に精通しています。たとえば、ある時点で、現在のビルドが私の製品の「RP_2012」ビルドを表すと判断する場合があります。後で、いくつかの機能が追加された後、「RP_2013」バージョンなどが存在する可能性があります。

特定の「バージョン」で開発が終了したとしても、バグ修正をロールアウトする必要があるかもしれません。たとえば、私がAzureで作業していて、各顧客がマルチテナンシー契約ではなく独自のバージョンのソリューションを持っているとします(そうすることで、支払いを希望する場合に新しいバージョンの製品を提供できるようになるためです。アップグレードすると、新しい機能を課すのではなく、アップグレードの準備ができるまで、快適な古いバージョンの製品を使用できます)。TeamCity、FluentMigratorなどを組み合わせて使用​​するスクリプトがあり、特定の顧客が持っているバージョンを取得して、既存のデータを保持しながら自由にアップグレードできます。それで、

上記のようにラベル付きバージョンのアプローチと単一の「マスター」ブランチを使用する場合、そのようなバグ修正を展開することは不可能かもしれません。代わりに、各バージョンに独自のブランチを与えると、各「バージョン」ブランチの祖先から派生した個別のブランチでバグ修正を実行し、後でその1つのブランチをいくつかの異なるバージョン固有のブランチにマージすることが可能でしょうか。枝?または、Rebaseを使用して、バージョン10、11、12に影響するバグ修正があり、それらの「バージョン」がマスターブランチに沿ったポイントとラベル付けされている場合、そこから分岐できるようにするための賢い方法はありますか?マスターで「バージョン10」とラベル付けされたポイント、および何らかの形でマスターをリベースして、上記のバグ修正ブランチで行われる修正に基づいて、これにより、バージョン10以降のすべてが、特定のブランチアドレスの修正から利益を得ることができますか?同時に、もちろん、新しい機能は、マスターのヘッドから分岐してマージすることによって実行されます。

私の質問と根本的な意図が十分に明確であることを願っています。基本的に、特定の製品のさまざまなバージョンを1つのマスターブランチに保持するのが最善かどうかを知りたいと思います。そして、もしそうなら、必要なときに/必要に応じて各バージョンにロールインできるバグ修正を実装するための最良の方法。これには、単一のブランチを複数の個別の子孫ブランチにマージすることが含まれる場合があります。または、すべてのバージョンが存在する単一のブランチをリベースする必要がある場合もあります。あるいは、皆さんはもっと賢い方法を知っているかもしれません。

提案を事前に感謝します。

4

2 に答える 2

2

これには「gitflow」を使用することをお勧めします。これは、説明しているユースケースを処理するためのgitの拡張機能であり、1つのマスターブランチと開発ブランチ、個別のリリースブランチ、および個別の機能ブランチを備えています。使用される分岐モデルの詳細については、これこのブログ投稿を参照してください。

説明している目的でリベースを使用する場合は、十分に注意する必要があります。Rebaseはバージョン履歴を書き換えます。これにより、「異なる」バージョン履歴を持つ人々からのコミットがある場合、非常に混乱し、困難になります。

于 2013-03-24T13:48:31.237 に答える
1

ここで何が最善かを定義する客観的な方法はないと思います。

個人的には、リリースごとに1ブランチのモデルを常に使用しています。特に、複数のクライアントがある場合はそうです。クライアントでさえカスタム機能を要求することがあるので、マイナーリリースのためにそのブランチから分岐します。

あなたの場合、マルチブランチモデルを使用していて、いくつかのブランチに適用したいバグ修正があると仮定すると、その修正を選択して、それを必要とするブランチにコミットすることができます。

また、この質問を確認してください。質問者は、同時に複数のブランチにコミットするためのスクリプトを提供します。そのことについてはチェリーピックを使用します。

于 2013-03-24T13:40:21.613 に答える