私たちは、いつでも複数のリリースが本番環境にある製品のワークフローを管理しています。これはチームにとって比較的新しい状況であり、我々はこれを処理するために最善のものかどうかは確かではない。私たちはgitをプライベートbitbucketリポジトリと共に使用しています。gitで複数の同時リリースを管理する
以前は、開発/マスター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で何かを逃してしまい、管理しやすくなりましたか?
これは具体的な答えがあるものよりも哲学的な問題のように聞こえます。 – tadman
私はそれを見ることができますが、私は実際にそれを行うための "最良の"方法ではなく、実装するプロセスを探しています。 – Brian
私はあなたが何を得ているかを知っています。それは悪い質問ではありませんが、ここのフォーマットではあまりにも開放的です。あなたが提示したオプションは機能する可能性があるので、技術的に間違ったものはありません。これは、物事を議論することができ、人々が話を分かち合うことができるフォーラムで、この質問/回答のフォーマットにあまり適していないようなフォーラムで、よりよく提示されるものです。 – tadman