GitHub Flowモデル
メインブランチはmasterの１つだけ、常にデプロイ可能な状態に維持するというシンプルなブランチモデルです。プルリクエストを作って、レビューしてもらって、マージします。
これは頻繁にリリース（デプロイ）する開発に適したブランチモデルです。
masterブランチ
現在の製品のメインブランチです。常にデプロイ可能な状態です。
featureブランチ
１ 新しい作業を開始するときは、わかりやすい名前のブランチをmasterから分岐します。
２ ローカルでコミットして、同じ名前でリモートにもpushします。
３ フィードバックやヘルプが必要なとき、
またはマージの準備ができたらプルリクエストを作成します。
４ 他のメンバーがレビューして確認したら、masterへマージできます。
５ masterにマージしたらデプロイできます。
「わかりやすい名前」としか説明されていませんが、それが難しいんですよね。
筆者はIssue番号と合わせて、feature/123 のようにつけています。
git-flowモデル
masterブランチ
現在の製品のメインブランチです。originに常に存在します。
developブランチ
次回リリース用のメインブランチです。originに常に存在します。リリース時にmasterへマージします。
featureブランチ
新しい機能を開発するための開発者用のブランチです。Issueの作業を開始するときに、developから分岐して、Issueの作業が完了したら、developへマージします。developへマージしたら削除します。
例：feature/123 （123はIssue番号）
releaseブランチ
次回リリースが近くなったら、developから分岐して、developとmasterへマージします。リリース担当者用のブランチです。リリースしたら、削除します。
例：release/1.2
hotfixブランチ
現在の製品バージョンのバグフィックス用で、開発者ローカルブランチです。masterから分岐して、masterとdevelopへマージします。マージしたら削除します。
例：hotfix/123（123はIssue番号）
GitLab Flowモデル
productionブランチモデル
featureブランチ
GitHub Flowと同じ使い方です。masterから分岐して、プルリクエストして、masterへマージします。
masterブランチ
製品のメインブランチです。masterにマージするタイミングで、本番環境へデプロイできるとはかぎりません。本番環境へデプロイする準備ができたら、productionブランチへマージします。
productionブランチ
本番ブランチです。本番環境にデプロイされます。
環境ブランチモデル
featureブランチ
GitHub Flowと同じ使い方です。masterから分岐して、プルリクエストして、masterへマージします。
masterブランチ
製品のメインブランチです。ステージング環境へデプロイされます。ステージング環境でのテストに合格したら、pre-productionへマージします。
pre-productionブランチ
本番直前環境ブランチです。本番直前環境にデプロイされます。本番直前環境でのテストに合格したら、productionブランチへマージします。
productionブランチ
本番環境ブランチです。本番環境にデプロイされます。
リリースモデル
ソフトウェアを外部にリリースする場合、バージョンごとのリリースブランチで作業する必要があります。
featureブランチ
GitHub Flowと同じ使い方です。masterから分岐して、プルリクエストして、masterへマージします。
masterブランチ
製品のメインブランチです。ステージング環境へデプロイされます。ステージング環境でテストします。
各種のバグ修正は、まずmasterへマージされて、各リリースブランチへcherry-pickされます。
リリースブランチ
各バージョンごとのリリースブランチです。
例：2-3-stable、2-4-stable