バグ修正はgit-flowモデルのどこにありますか？
Git-flow モデルの修正プログラムは、特定のhotfix-*ブランチとリリース前の小さな統合の修正はrelease-* ブランチ。以前のバージョンからの一般的なバグ修正には場所がないようです。
どこに表示されますか？彼らは自分の中にいる必要がありますbug-*ブランチはdevelopから分岐しています（featureブランチと同じように）？
短い答え：はい、計画されている次のリリースに入るバグ修正のブランチは機能ブランチにあるはずです。バグ修正のために機能ブランチまたはこれらのブランチに名前を付ける方法は、あなたとチームの標準次第ですが、Gitflowをフォローしている場合、それらは同じように扱う必要があります。
Bart van Ingen Schenauのコメント は良い点をもたらします。
Gitflowには5つのブランチタイプがあります：master、develop、ホットフィックスブランチ（接頭辞hotfix-）、リリースブランチ（接頭辞release-、および機能ブランチ。 masterおよびdevelopブランチは実行時間の長いブランチであり、それらに直接コミットすることはありません。 release-ブランチは、特定のリリースに線を引き、次のバージョンの識別とリリース間のバグ修正をサポートするために作成されます。 hotfix-ブランチは、重要な、サイクル外の本番環境へのリリース用です。 feature-ブランチは、将来のリリースに向けて個々の機能を開発するためのものです。
PRが使用されている環境から来て、個々の開発者が機能ブランチにコミットすることを除いて、master、develop、またはリリースブランチに直接コミットする必要はありません。これにより、変更が行われる前に、適切なテストカバレッジを確保し、CI環境でテストに合格するとともに、すべての変更がコードレビューされることが保証されます。リリース前のバグ修正または変更をリリースブランチに直接コミットし、それらを開発ブランチに組み込んでから機能ブランチにプルすることで問題が発生します。
あなたの特定のケースでは、release-ブランチは適切な場所ではありません。ソフトウェアはすでにリリースされており、masterにあります。リリースがマスターにマージされ、そこにタグが付けられると、その特定のリリースのリリースブランチはその目的を達成し、必ずしも存在する必要がなくなります。ブランチのクリーンアップに積極的に取り組んでいる場合（誰もがそうすべきだと思います）、これはオプションではありません。
修正が重要でない場合は、修正プログラムのブランチも適合しないようです。ホットフィックスブランチの目的は、進行中の開発を妨げることなく、重要な変更を迅速に本番環境に導入できるようにすることです。これらを使用することは、開発チームの標準ではなく、例外であるべきです。一般に、重要なホットフィックスは例外的なケースです。
残っているのは機能ブランチだけです。 機能ブランチに関する質問でリンクされているページのセクション は、機能ブランチが「トピックブランチと呼ばれることもあります」とさえ言っていることに注意してください。変更が今後のリリースを対象としていて、修正プログラムの基準を満たさない場合は、これらのブランチのいずれかにあるはずです。
単一のコミットの場合は、十分に識別されたコミットを作成して、開発ブランチの上にプッシュするか、機能ブランチを作成します。
Git-flowの作者から、あなたが何を求めているかを正確に述べたコメントもあります： Missing bugfix branch＃24