マスターブランチとリリースブランチは何のためにありますか？
私の英語はgit flowの説明を理解するのに十分ではありません
私の理解のために。
Master branchは、ユーザーが市場にダウンロードできる既製品用です。
しかし、release branchesがあります。これらのブランチが誰のためにリリースされるのか、私には考えがありません。
顧客向けのリリース？またはQAのために？
developがリリースに十分な機能を取得したら（または事前に決められたリリース日が近づいている）、開発からリリースブランチを分岐します。このブランチを作成すると、次のリリースサイクルが開始されます。したがって、このポイントの後に新しい機能を追加することはできません。バグ修正、ドキュメントのみ生成、およびその他のリリース指向のタスクは、このブランチに配置する必要があります（テストも含む）。出荷の準備ができると、リリースはマスターにマージされ、バージョン番号でタグ付けされます。さらに、開発にマージする必要があります。リリースが開始されてから進行している可能性があります。
専用ブランチを使用してリリースを準備すると、あるチームが現在のリリースを磨きながら、別のチームが次のリリースの機能の作業を続けることができます。また、明確に定義された開発フェーズを作成します（たとえば、「今週はバージョン4.0を準備しています」と言って、実際にリポジトリの構造で確認するのは簡単です）。
詳細 here ブランチ用
元の V.Driessenによる投稿 で説明したように：
Masterは、常に本番稼働状態を反映する永続的なブランチです。そのため、ユーザーが市場にダウンロードできる既製品用です。
Releaseは、新しい製品リリースの準備をサポートする一時的なサポートブランチです。これは、minasが指摘したように、主にバグ修正、ドキュメントなどを意味します。
リンクした図では、はい、masterはユーザーにリリースされる「準備ができた製品」に使用されています。 （ただし、誰もがこのようにmasterを使用するわけではありません。）
図では、チームが新しい「すぐに使える製品」リリースを準備するたびに、新しい「リリース」ブランチを作成します。彼らはリリースを準備している間、「リリース」ブランチに新しい機能を追加しません。新しい機能を追加すると新しいバグが発生する可能性があり、公開する前に「リリース」バージョンをできるだけ安定させようとしています。 。 「リリース」ブランチにコミットを追加して、最終テスト中に見つかった問題を修正したり、大まかなスポットを磨いたりします。したがって、「リリース」ブランチを作成すると、「機能凍結」ポイントがマークされます彼らが既に開発した機能は、次のパブリックリリースに組み込まれます。
製品の新しいバージョンを公開する準備ができたら、「リリース」ブランチをmasterにマージし、公開ダウンロード可能な製品のビルドに使用されるコミットにタグを付けます。 （バージョン1.0をリリースしている場合、コミットにタグを付けることがあります1.0、 等々。）
同時に、彼らは新しい機能に取り組んでいるときに、新しい「機能」ブランチを作成し（developから分岐）、それらにコミットします。新しい機能が動作しているとき、彼らはそのブランチをdevelopにマージします。 developは常に前進しています。