2017-03-15 17 views
0

私はgitFlowに従ってリリースを行うためにjgitflow Mavenプラグインを使用しています。これは正常に動作します。私のリリースが遅れると問題が発生するので、2つのリリースを同時に行う必要があります。GitFlowを使用中のjgitflowおよびパラレルリリース

例を考えてみましょう。

GitFlowによると、私の生産状態をマスターブランチにコミットする必要があります。したがって、1.0,1.1,1.2のリリースをマスターにマージします。 いつか2.0リリースが開始されました。私は2.0リリースをマスターにコミットさせる必要があります。しかし、もし1.xxがまだ完成していないのであれば?

2.0の後に1.xxをコミットするのは悪い習慣のように見え、おそらくマージの競合が発生します。

だから私のアイデアは

  1. に最後の1.xxのリリースから分岐1.xxのための偽のdevのブランチを作成することです。それはそのブランチから

  2. 実行1.xxののjgitflowリリースを1.11devないと習得することはもはやそれらをマージしますが、再度、最後の1.xxのリリースから作成された偽のマスターブランチに、

  3. 1.11masterそれを呼び出すことができます呼び出すことができます

    run 2.xxはマスターブランチから解放され、通常はマスターにマージされます。

これは、私のマスターブランチに1.xxリリースの一部だけが含まれることを意味します。それは良いことではありません。 これは、1.xxdevから 'true' devへの修正を別々にマージする必要があることを意味します。

私の理解は正しいですか? 良い方法がありますか?

答えて

0

あなたがここで触れているのは、support branchのコンセプトです。ここで、2.xの作業を開始しても、以前のリリースで開発を続ける必要がある場合は、1.x開発用のサポートブランチを作成します。

我々はGitVersionツールでこれをカバーしている、といくつかのサポートドキュメントはここにあります:

http://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

ボトムラインは、あなたがこのポイントに得れば、あなたは本質的gitflowの2つのインスタンスを実行している、です。 1つはアクティブな開発ブランチ用で、もう1つはサポートブランチ用です。