私は現在、git-flowをよく調べており、自分が関わっているプロジェクトでgit-flowをどのように使用するかを理解しようとしています。
私はさまざまなgit-flowチュートリアルを見てきましたが、gitについてはかなりよく知っています。したがって、gitだけのヒントは必要ありませんが、git-flowを使用したワークフローについて直接説明する必要があります。
状況は次のとおりです。
バージョンをリリースすると（1.0と呼びましょう）、これは開発の分岐になります。これは問題ありません。今、私が2.0で作業を開始し、新しい機能を追加しているとしましょう。そしてもちろん、完了したら、それらをマージして開発に戻したいと思います。これで、1.0での修正プログラムは問題ないので、いくつかのバージョン1.0.1、1.0.2などを作成するとします。これらはすべて開発ブランチも更新します。これも素晴らしいことです。これまでのところ面倒ですが、2.0の機能と1.0.xの修正プログラムを個別に開発できます。
ただし、誰かが1.1リリースの新機能を要求したとします。今、私は問題を抱えています。機能ブランチを作成する場合、これは開発ブランチに基づいており、このブランチにはすでに2.0のものが含まれている可能性がありますが、この1.1リリースでは必要ない可能性があります。
これらの2.0と1.1の変更を独立して処理する簡単な方法はありますか？
私がすでに見ているいくつかの可能性があります：
開発の最後のリリース位置に新しいブランチを作成します。開発をこの位置にリベースし、他の開発ブランチの名前を変更します。ただし、このブランチには1.0.1などのホットフィックスは含まれません。
2.0が完了する前に、2.0の機能をマージして戻さないでください。ただし、最後の瞬間まで、マージされていない多くの変更を開いたままにしておく必要があります。また、2.0 getがリリースされ、その後1.0.xへの変更が要求された場合、これは役に立ちません。
これはgitflowでまったく可能ですか？つまり、新しいリリースの作業が開始または終了した後は、以前のリリースに基づいてリリースしますか？