GitFlowブランチ戦略、ただし開発ブランチなし
私はGitFlow分岐戦略のようなものを採用することを考えています。永続的なdevelopブランチを使用する代わりに、各スプリントの先頭に（releaseからの）スプリントごとにmasterブランチを作成します。機能ブランチはリリースブランチにマージされます。 CIプロセス（TeamCity）は、最新のリリースブランチ（バージョン番号のサフィックスに基づく）を統合およびQA環境にデプロイするように構成されます。
ここでの私の考えは、リリース時にdevelopブランチを維持する必要を回避し、masteranddevelopにマージする必要を回避することです準備ができています。
このアプローチの潜在的な欠点はありますか？
明確にするために：
- スプリント/リリースサイクルは通常約3週間です
- すでにリリースブランチにマージされている可能性がある単一の機能ブランチを時々リリースする機能が必要です
いくつかの欠点がありますが、あまりメリットはありません。
マスターが「最新リリースバージョン」の反映を停止しない限り、マスターへのマージの必要性をどのように回避しているのかわからない
私が目にする主な欠点は、「開発」動作が発生するが、すべてのスプリントで「開発」の名前が変更され、CIがスプリントごとに異なるブランチを指すようになることです。
私の意見で2番目に大きな欠点は、バグの修正です。古いリリースのバグを修正する場合は、現在のリリース（および、顧客が異なるバージョンを使用している場合は、おそらくいくつかの中間リリース）にそれらを移植する必要があります。ブランチ構造でそのプロセスをより困難にし、3つを超えるブランチ統合を潜在的に管理しました。
マージを回避しようとしている場合は、ブランチングのメリットは得られません。
あなたはまだGitFlowをやっているようですが、開発ブランチの名前をいじっているだけです。
ここで大きな問題があります。名前の変更/再分岐ではなく、選択した名前を使用します。
ブランチにリリースのバージョンの名前を付けます。ただし、リリースの時点に到達する前に、リリースバージョンを知ることはできません。
例えば：
ブランチをrelease_1.0.0.2と呼びますが、それを完了する前に、ホットフィックスを実行する必要があります。今あなたのリリースは1.0.0.3になります
ビルド番号を省略してブランチrelease_1.0.1.xを呼び出すことにしましたが、機能の1つが重大な変更を導入していることに気づきました。次に、それをrelease_1.2.0.xに変更します
Release_1.1.x.xで機能を開始したが、スプリントの終了に間に合わなかった。これをrelease_1.2.x.xにマージする必要があります
全体的に見て、リリースブランチを事前にリリースするよりも、マスターからリリースブランチにブランチし、自動生成されたビルド番号やタグ付けなどを使用して、git /ソース管理でリリースバージョンにラベルを付ける方がよい
開発ブランチを維持したくないことは十分理解できます。マスターと開発の両方を維持するのは面倒です。開発ブランチの使用も廃止しました。マスターが常に動作状態であることを確認します。潜在的にリリース可能なコードのみがマスターになります。機能ブランチを使用してこれを実現します。
私たちは通常マスターからリリースしていましたが、前回のメジャーリリースでマイナーな問題が発生しました。「カットオフ」がいつリリースされたかが不明であり、リリースがテストされなかったため、希望どおりの結果が得られませんでした。
将来的には、マスターの代わりにリリースブランチをリリースすることについて話します。今日、これらのリリースブランチがありますが、今日はリリースする前にそれをマスターにマージしますが、これは最適ではありません。
リリース直後に、リリースブランチがマスターにマージされます。
あなたが説明する流れは理想的な設定のように聞こえ、私には大きな欠点はありません。将来的には、おそらく同じようなことをするでしょう。
私はあなたのブランチスタイルはあなたのリリース戦略に基づいているべきだと信じています：
- 製品/ライブラリ開発
- スプリントベースのリリース
- 継続的な展開
歴史的に、私は製品とライブラリの開発に焦点を当ててきました。その世界では、通常、複数のバージョンが同時に使用されており、実装はバージョン間で大幅に異なる可能性があります。そのため、あるバージョンのバグ修正を単純に別のバージョンにマージすることはできません。これをサポートするには、次の構造を使用します。
- 機能ブランチ：リリースの一部として開始する個々の作業単位ただし、そのリリースで終了する場合と終了しない場合があります。
- リリースブランチ。機能の押しつぶされたコミットを受け取ります（競合を最小限に抑えるために、機能ブランチに定期的にマージされます）。
- 最新リリースコードベースのバージョンを含むマスター。
ここで重要なのは、Releaseブランチがマスターにマージされた後も存続し、他の場所に存在するかどうかわからない変更を受け取ることです。したがって、たとえば、ブランチrel_1_9で作業しているときに、rel_1_2でバグ修正を行い、そのバグ修正にrel_1_2_7のタグを付けることができます。
このアプローチでは、実際にはマスターは必要ありません。リリースタグから新しいリリースブランチを作成し、それをデフォルトブランチとして設定できます。しかし、masterを好む人もいるので...
代替環境は、通常のリリースを作成し、古いリリースに戻さない環境です（たとえば、典型的なホスト型アプリ）。その場合、分岐戦略は、継続的なデプロイメントを実行するか、スプリントを実行するかによって異なると思います。
スプリントの場合、開発は統合ブランチとして役立ちます。すべての新しい作業はフィーチャーブランチからマージされますが、スプリントが完了するまでマスターにマージされません。スプリント中に、ホットフィックスがマスターにコミットされ、その後、開発にマージされる場合があります。リリースごとに別々のブランチを作成する理由は本当にありません。マージ後にブランチが変更されない場合、それは意味的にはタグと同じです。
また、継続的なデプロイを行う場合は、FeatureブランチとMasterブランチを保持して、開発を取り除くことをお勧めします。複数の開発者が自分の作業をDevelop before Masterにマージする場合、will意図しない変更がマージされてデプロイされる状況になります。
私の会社では、同様のアプローチを使用しています（各スプリントの後にreleaseブランチを作成していますが、developではなくmasterを使用しないことにしました） 。根拠は、リリースを「永久に」維持することだと思います。
この戦略は、製品が複数のマシンにインストールされ、それらのインストールを別のバージョンにアップグレードするタイミングを制御できない場合に意味があります。 GitFlowをフォローしている場合、古いリリースに到達できますが、特に新しいバージョンをmasterにマージした後は、パッチを適用するのはそれほど簡単ではありません。そのような製品は、例えばデスクトップアプリケーションまたはスタンドアロンシステム。
この戦略は、製品がサービスであり、いつアップグレードするかを完全に制御できる場合にはあまり意味がありません。サーバーに新しいバージョンをインストールすると、クライアントはどのバージョンに対応するかを選択できなくなります。任意のWebサービスが例です。
要するに、どちらの戦略も実行可能であり、どちらにも利点と欠点があります。あなたが持っているリリースに対する制御の度合いが、あなたの決定を導くべきものだと思います。