機能ブランチのサブブランチを作成するためのGitFlowの適切なプロセス/命名規則は何ですか？
開発規約にGitFlowを使用しています。一般的に言って、私はユーザーストーリーとそれに対応する機能ブランチを私の開発ブランチから作成し、それに取り組んでいます。ストーリーが完了すると、機能が完成し、マージ（リベース）されて開発に戻ります。
しかし、私は今、私の機能がかなり叙事詩的であるという問題に遭遇しています。機能（エピック）を提供する前に、かなりの量の開発が必要になります（単一の成果物として提供する必要があります）。ただし、1つの機能ブランチでのみ機能することは適切ではありません。
そうは言っても、このようなことをするための適切な慣習は何ですか？ feature/MyEpicNameという名前のエピックブランチを作成し、すべての開発者にfeature/MyEpicNameを同等の「開発」ブランチとして使用するように指示するだけですか？次に、そのブランチに基づいてすべての機能ブランチを作成し、変更をそのブランチにマージします。
しかし、私がそのようなプロセスに従うと、私の命名規則が不安定になり始めます。通常（慣例により）、feature/xxxxは、developブランチからの機能ブランチを意味します。私の開発者が「開発」ブランチとしてfeature/MyEpicNameを使用する場合、彼らはまだ独自の機能/ブランチを作成します。しかし、どの機能が開発から分岐し、どの機能がエピックから分岐するのかを理解しようとすることは、巨大な混乱になります。
これらの種類の状況に対処するための受け入れ可能な命名規則/プロセスはありますか？彼らは機能ブランチを機能/ MyEpicName/xxxxyyyyと呼びますか？
後者はツール/スクリプトの一部を壊しますか？例：gitflowフック、smartgitなど.
機能ブランチでは、feature-name/featureの規則を使用します。たとえば、メイン機能ブランチとしてのrewrite-quote/featureです。ここでのキーワード機能は、主要機能の分岐としてそれを知らせるために使用される規則です。
サブブランチは、feature-name/subbranch nameのような名前になります。例：rewrite-quote/quote-model
これの利点は、各ブランチがどこに属しているかを簡単に確認できることです。一部のツールは、それらをフォルダーのようなビュー（sourcetree）にグループ化します
これには慣習はありません。おそらく、長命の機能ブランチは悪いもの（tm）と見なされているためです
この叙事詩がソフトウェアの次のバージョンである場合、開発ブランチが適切な場所です。その「サブ機能」は、通常の方法で作成する機能ブランチであり、すべて完了したら、開発をマスターにマージしてリリースします。
エピックが完了する前に配信される成果物がある場合、それらをエピックブランチにマージして戻す必要があるため、変更を統合したり、再テストしたりする間、進行が遅れます。
私はこの状況に対する解決策があるとは思いません。機能切り替えを使用して、未完成の機能をオフにし、エピックが終了したらすべてオンにすることができます。しかし、これはマスターでは未完成の作業になるため、理想的ではありません。
私の意見では最良のアプローチは、エピックを再評価し、通常のリリースサイクルで完了できる小さな成果物に分割することです。
たとえば、APIレイヤーがまだそれらを使用していない場合でも、データベースを新しいテーブルでアップグレードできますか？次に、フロントエンドなどで使用されていなくても、APIレイヤー