gitで複数の同時リリースを管理する

Question

私たちは、いつでも複数のリリースが本番環境にある製品のワークフローを管理しています。これはチームにとって比較的新しい状況であり、我々はこれを処理するために最善のものかどうかは確かではない。私たちはgitをプライベートbitbucketリポジトリと共に使用しています。

以前は、開発/マスターgitフロータイプのワークフローを使用していましたが、うまく機能しました。最近では、クライアントが複数のバージョンをプロダクションに入れているので、それぞれのプロダクトを自分のプロダクトであるかのようにサポートする必要があります。

など。私たちは1.1,1.2,1.5を持っており、他のものに影響を与えずにそれぞれを作業し、展開することができなければなりません。しかし、理想的には、ブランチ間でいくつかの変更が共有されるのと同じプロジェクトにありますが、他のブランチは変更されません。私たちが調査している

2つの可能性：

• を、例えばV1.1-V1.1開発マスター、V1.2-開発を開発/マスターのアイデアにこだわっが異なるバージョンにそれを拡張し、 v1.2-master、etc ...これは以前のフローとまったく同じですが、master/developの3つのバージョンがあります。
• 各バージョンv1.1、v1.2、v1.5に1つのブランチを使用し、リリース時にタグを付けます。作業をする必要がある場合は、タグでプルして作業し、新しいブランチにチェックアウトしてタグを付け直します。このバージョンは非常にclunkyのようです。
• 私もgitの作業ツリーを見てきましたが、それは複数の同時のブランチを提供しますが＃1のようなブランチの倍数を提供しないので＃2のようです。

誰もこの種の設定を経験していますか？ ＃1は正しい方法ですか？ ＃2や＃3で何かを逃してしまい、管理しやすくなりましたか？

Answer 1

私の会社は、バージョンごとに別々の枝を維持し、そう1.1、1.2、2.1、など私たちは、その後、ポイントリリースをマークするために、各ブランチ内のタグを使用するので、1.1.7、1.2.4、2.1.2。

支店はメジャー/マイナーバージョンに使用されます。メジャー/マイナーバージョンはサポート/メンテナンスの決定ポイントです。私たちは、この分離に基づいて、過去数回の「リリース」しかサポートしていません。

各ポイントのリリースは前方進行です。リリース1.1.7は決してなく、実際には1.1.6に変更されます。見つかった問題は1.1.8で解決され、適切にタグ付けされます。

これはあなたの＃2と似ていますが、実際には「タグでプル」することはありません。我々はまだ各リリースの最新コミットを指しているブランチに基づいて動作します。タグはより歴史的です。

これは、組織がリリースを定義し、それらのリリースをサポートしているかどうかによって大きく異なります。これは私たちの組織にとっては非常にうまく機能し、時間の経過とともに変更が適切なチャネルになり、gitでの最小の戦闘が必要であることを保証することが容易になりました。