現在のリリースには含まれない機能を扱う

Question

あなたは現在、製品のバージョン3にいるとし、次のバージョンは4であるとします。ただし、リリースサイクルよりも開発に時間がかかる機能があります例えば、バージョン5までは準備ができていません（もっと長くてもかまいません）。 git-flowでこの問題に対処する最善の方法は何ですか？このワークフローは実際にこのようなことを許してくれないようです。次のリリース後にリリースの実際の表記はありません。

ここで私は作業に使用していますが、次のリリース、つまり上記の例ではrelease/4のブランチがありました。そして、マスターブランチは、リリース/ 5以降の次のリリースのためのものです。バージョン4ではなくバージョン5にない機能は、マスターブランチから開発されます。リリース/ 4のフィーチャーブランチはリリース/ 4にマージされます（バージョン4がリリースされた場合にはアップデートになります）。そしてマスターになります（ただし、マスターにもマージするのを忘れた場合は大きな問題ではありません）次のリリースに移ったとき、私たちは再びマスターを分けて、つまりリリース/ 5ブランチを作成します。リリース/ 5にある機能はリリース/ 5を分岐し、リリース/ 6で実行されるものはすべてマスタになります。

時間のかかる機能を簡単に開発できるようになったが、まだリリースを意識しているという意図があったため、このシナリオではこのワークフローが好きでした。私はgit-flowの変更を使ってこれがどのように達成されるのかという戦略に興味がありますか？

Answer 1

可能であれば、gitflowではなく「git workflow」と考えることができます。
私は「Handle git branching for test and production」

にアイデアを提示し、それをあなたが各リリース後に再作成することを、はかない「next」枝（V4用、1 V5以降）を持つことです。

あなたのfeatureブランチをマージします。これらfeature枝は次のreleaseの準備ができている場合（releaseからdevelopをマージするときにgitflowで行うように）しかし、あなたはreleaseに「next」ブランチをマージしません。 featureブランチ自体をreleaseにマージします。

このようにして、長期的な機能のライフサイクルを必要に応じて管理し、適切な（v4、v5、...）次のブランチに統合して検証することができます。