git-flowとは、A successful Git branching modelで紹介されている開発モデルを実装したもので、長らく更新がありませんがGitHubにて公開されています(https://github.com/nvie/gitflow)。
中央リポジトリは永遠の生涯ずっと、2つのメインブランチを保持します。
originのmasterブランチの他にdevelopと呼ばれるもう一つのブランチが存在する形です。
ここでorigin/masterは、製品として出荷可能な状態を常に反映する、ソースコードのHEADのありかであるメインブランチだと考えます。
origin/developは、次のリリースのための最新の開発作業の変更を常に反映する、ソースコードのHEADのありかであるメインブランチだと考えます。
developブランチのソースコードが安定し、リリースの準備ができたとき、developブランチの全ての変更はmasterブランチへマージされ、リリース番号をタグ付けされることになります。
したがって、masterへ変更がマージされるのは新しい製品がリリースされることと同義であると言えます。理論的には、masterにコミットがあるときは毎回Gitのフックスクリプトで自動ビルドを行い、そしてプロダクションサーバにソフトウェアをロールアウトします。
masterとdevelopのメインブランチのそばで、開発モデルはチームメンバ間の平行開発を助ける様々なサポートブランチを用い、機能の追跡、製品リリースの準備、製品に起きた問題を素早く修正すること、などを容易にします。メインブランチと異なり、これらのブランチは寿命が決まっており、使い終わったら最終的には削除されます。
それぞれのブランチは特定の目的を持ち、どのブランチから分岐するか、またどのブランチへマージされるのかというのは厳密に決まっています。
技術的には、これらのブランチは特別なものではありません。上記のブランチの種類はあくまで意味付けを持たせただけで、普通のGitブランチです。
Featureブランチはdevelopブランチから分岐し、developブランチにマージされます。ブランチ名の慣習としては、master、develop、release-*、hotfix-*以外なら全て使えます。
Featureブランチ（もしくはTopicブランチとも呼ばれる）は今度のリリースに入る、または遠い将来のリリースに入るような新しい機能を開発するのに使われます。 ある機能を開発し始めるとき、その時点ではその機能を含めるべきリリースがどれなのか不明です。Featureブランチの本質は、機能を開発している限りは存在しているが、最後にはdevelopにマージされるか捨てられます。
Featureブランチは典型的には開発者のリポジトリにだけ存在し、originには存在しません。
Releaseブランチはdevelopブランチから分岐し、developとmasterブランチにマージされます。ブランチ名の慣習としてはrelease-*が使われます。
Releaseブランチは新しい製品リリースの準備をサポートします。リリース前のマイナーなbug fixやリリースのためのメタデータの準備までさせてくれます。これらの全ての作業をリリースブランチ上で行うことで、developブランチはきれいな状態を保つことができます。
developから新しいReleaseブランチを分岐するためのタイミングの目安としては、developブランチがおおむねリリースできる状態になっていることです。 少なくともリリースのビルドのターゲットとされる全ての機能は、この時点でdevelopにマージされていなければなりません。
Hotfixブランチはmasterから分岐し、developとmasterにマージされます。ブランチ名の慣習としては、hotfix-*が使われます。
Hotfixブランチは現在の製品バージョンにあるクリティカルなバグを解決しなければならないときなどに使われます。