バグ修正はgit-flowモデルのどこにありますか？

一般的に呼ばれる、Git-flowモデルの修正プログラムは、特定のhotfix-*ブランチに導入され、リリースの直前に小さな統合修正がrelease-*ブランチに導入されます。前のバージョンからの一般的なバグ修正には場所がないようです。

どこに表示されますか？彼らbug-*はdevelop（ちょうどfeatureブランチのように）分岐する独自のブランチにあるべきですか？

簡単な答え：はい、予定されている次のリリースに入るバグ修正のブランチは、機能ブランチにあるべきです。機能ブランチまたはバグ修正のためにこれらのブランチに名前を付ける方法は、あなたとあなたのチームの標準次第ですが、Gitflowをフォローしている場合は、同じように扱われるべきです。

バート・ファン・インゲン・シェナウのコメントは良い点をもたらします。

：Gitflowは5分岐タイプありmaster、develop（接頭辞、修正プログラムの枝hotfix-）、リリースブランチ（接頭辞release-ザ、および機能ブランチをmasterし、develop枝が実行時間の長い枝であり、あなたがそれらに直接コミットしません。release-枝が線を描画するために作られています特定のリリースの場合は、次のバージョンの識別とリリースの間のバグ修正をサポートします。hotfix-ブランチは、特に重要なサイクル外の本番リリースfeature-用です。ブランチは、将来のリリースの個々の機能の開発用です。

PRSは機能ブランチにコミットする個々の開発者は別に使用している環境から来て、何も直接にコミットすべきではないmaster、developまたはリリースブランチ。これにより、すべての変更がコードレビューされ、適切なテストカバレッジが確保され、変更が行われる前にCI環境でテストに合格することが保証されます。 tプレリリースのバグ修正または変更を直接リリースブランチにコミットしてから、開発および機能ブランチにそれらを取り込むことに問題がある。

特定のケースでは、release-ブランチは適切な場所ではありません。ソフトウェアはすでにリリースされており、にありmasterます。リリースがマスターにマージされ、そこでタグが付けられると、その特定のリリースのリリースブランチはその目的を超えて存在し、必ずしも存在する必要はありません。ブランチのクリーンアップに積極的であれば（誰もがそうすべきだと思います）、これはオプションではありません。

修正が重要でない場合、修正プログラムのブランチはどちらにも当てはまらないようです。ホットフィックスブランチの目的は、進行中の開発を妨げることなく、誰かが重要な変更を本番環境に非常に迅速に取得できるようにすることです。開発チームの標準ではなく、これらを使用することは例外です。一般に、重要な修正プログラムは例外的なケースである必要があります。

残っているのは機能ブランチのみです。機能ブランチに関する質問でリンクされているページのセクションには、機能ブランチは「トピックブランチと呼ばれることもある」とさえ記載されていることに注意してください。変更が今後のリリースを対象としており、修正プログラムの基準を満たしていない場合、これらのブランチのいずれかにあるはずです。

単一のコミットの場合は、明確に識別されたコミットを作成し、開発ブランチの上にプッシュします。それ以外の場合は、機能ブランチを作成します。

また、git-flowの作者から、あなたがまさに求めていることを言っているコメントがあります：バグ修正ブランチの欠落＃24