web-dev-qa-db-ja.com

GitFlowブランチ戦略、ただし開発ブランチなし

私はGitFlow分岐戦略のようなものを採用することを考えています。永続的なdevelopブランチを使用する代わりに、各スプリントの先頭に(releaseからの)スプリントごとにmasterブランチを作成します。機能ブランチはリリースブランチにマージされます。 CIプロセス(TeamCity)は、最新のリリースブランチ(バージョン番号のサフィックスに基づく)を統合およびQA環境にデプロイするように構成されます。

ここでの私の考えは、リリース時にdevelopブランチを維持する必要を回避し、masteranddevelopにマージする必要を回避することです準備ができています。

このアプローチの潜在的な欠点はありますか?

明確にするために:

  • スプリント/リリースサイクルは通常約3週間です
  • すでにリリースブランチにマージされている可能性がある単一の機能ブランチを時々リリースする機能が必要です
5
Matthew Dresser

いくつかの欠点がありますが、あまりメリットはありません。

マスターが「最新リリースバージョン」の反映を停止しない限り、マスターへのマージの必要性をどのように回避しているのかわからない

私が目にする主な欠点は、「開発」動作が発生するが、すべてのスプリントで「開発」の名前が変更され、CIがスプリントごとに異なるブランチを指すようになることです。

私の意見で2番目に大きな欠点は、バグの修正です。古いリリースのバグを修正する場合は、現在のリリース(および、顧客が異なるバージョンを使用している場合は、おそらくいくつかの中間リリース)にそれらを移植する必要があります。ブランチ構造でそのプロセスをより困難にし、3つを超えるブランチ統合を潜在的に管理しました。

マージを回避しようとしている場合は、ブランチングのメリットは得られません。

1
Bruno Guardia

あなたはまだ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 /ソース管理でリリースバージョンにラベルを付ける方がよい

1
Ewan

開発ブランチを維持したくないことは十分理解できます。マスターと開発の両方を維持するのは面倒です。開発ブランチの使用も廃止しました。マスターが常に動作状態であることを確認します。潜在的にリリース可能なコードのみがマスターになります。機能ブランチを使用してこれを実現します。

私たちは通常マスターからリリースしていましたが、前回のメジャーリリースでマイナーな問題が発生しました。「カットオフ」がいつリリースされたかが不明であり、リリースがテストされなかったため、希望どおりの結果が得られませんでした。

将来的には、マスターの代わりにリリースブランチをリリースすることについて話します。今日、これらのリリースブランチがありますが、今日はリリースする前にそれをマスターにマージしますが、これは最適ではありません。

リリース直後に、リリースブランチがマスターにマージされます。

あなたが説明する流れは理想的な設定のように聞こえ、私には大きな欠点はありません。将来的には、おそらく同じようなことをするでしょう。

1

私はあなたのブランチスタイルはあなたのリリース戦略に基づいているべきだと信じています:

  • 製品/ライブラリ開発
  • スプリントベースのリリース
  • 継続的な展開

歴史的に、私は製品とライブラリの開発に焦点を当ててきました。その世界では、通常、複数のバージョンが同時に使用されており、実装はバージョン間で大幅に異なる可能性があります。そのため、あるバージョンのバグ修正を単純に別のバージョンにマージすることはできません。これをサポートするには、次の構造を使用します。

  • 機能ブランチ:リリースの一部として開始する個々の作業単位ただし、そのリリースで終了する場合と終了しない場合があります
  • リリースブランチ。機能の押しつぶされたコミットを受け取ります(競合を最小限に抑えるために、機能ブランチに定期的にマージされます)。
  • 最新リリースコードベースのバージョンを含むマスター。

ここで重要なのは、Releaseブランチがマスターにマージされた後も存続し、他の場所に存在するかどうかわからない変更を受け取ることです。したがって、たとえば、ブランチrel_1_9で作業しているときに、rel_1_2でバグ修正を行い、そのバグ修正にrel_1_2_7のタグを付けることができます。

このアプローチでは、実際にはマスターは必要ありません。リリースタグから新しいリリースブランチを作成し、それをデフォルトブランチとして設定できます。しかし、masterを好む人もいるので...

代替環境は、通常のリリースを作成し、古いリリースに戻さない環境です(たとえば、典型的なホスト型アプリ)。その場合、分岐戦略は、継続的なデプロイメントを実行するか、スプリントを実行するかによって異なると思います。

スプリントの場合、開発は統合ブランチとして役立ちます。すべての新しい作業はフィーチャーブランチからマージされますが、スプリントが完了するまでマスターにマージされません。スプリント中に、ホットフィックスがマスターにコミットされ、その後、開発にマージされる場合があります。リリースごとに別々のブランチを作成する理由は本当にありません。マージ後にブランチが変更されない場合、それは意味的にはタグと同じです。

また、継続的なデプロイを行う場合は、FeatureブランチとMasterブランチを保持して、開発を取り除くことをお勧めします。複数の開発者が自分の作業をDevelop before Masterにマージする場合、will意図しない変更がマージされてデプロイされる状況になります。

恥知らずな自己宣伝: http://www.kdgregory.com/index.php?page=scm.git

1
kdgregory

私の会社では、同様のアプローチを使用しています(各スプリントの後にreleaseブランチを作成していますが、developではなくmasterを使用しないことにしました) 。根拠は、リリースを「永久に」維持することだと思います。

この戦略は、製品が複数のマシンにインストールされ、それらのインストールを別のバージョンにアップグレードするタイミングを制御できない場合に意味があります。 GitFlowをフォローしている場合、古いリリースに到達できますが、特に新しいバージョンをmasterにマージした後は、パッチを適用するのはそれほど簡単ではありません。そのような製品は、例えばデスクトップアプリケーションまたはスタンドアロンシステム。

この戦略は、製品がサービスであり、いつアップグレードするかを完全に制御できる場合にはあまり意味がありません。サーバーに新しいバージョンをインストールすると、クライアントはどのバージョンに対応するかを選択できなくなります。任意のWebサービスが例です。

要するに、どちらの戦略も実行可能であり、どちらにも利点と欠点があります。あなたが持っているリリースに対する制御の度合いが、あなたの決定を導くべきものだと思います。

0
logc